service modules with initial user stories

[transmeta01]

Service modules

-Authentication and authorization
user can sign up for an account (register)
user can delete their account
user can log into their account
user can change/update their account information
every user has a role (regular or admin, more roles may be added)
note: user must have an account to make a purchase

-Order management
user with role admin can see the all orders
user with role regular can only see their own order(s)
every order shows the cart information details and the user who placed
the order
order has a date it was placed
order has a total price is calculated with tax (15%)

-Shipping
order has a shipping status (not yet, shipped, awaiting approval)
tracking (this will use a third party shipping service)

-Email/mailing list
import email list from a cvs and xml file format
select list of user to email
email single user

-Product/inventory management (available only to admin user)
user can update product information
user can upload new product (description, price, images)
user can remove product
user can add a new category
user can add a new brand
user can see the quantity of items available (per brand, per category)
each product must belong to a category
each product must belong to a brand
each brand must have one or more product

-Checkout/Payment
user update/add/remove items from cart
user can pay with paypal, visa, or american express credit card (this
will use a third party gateway payment service)

-Marketing/Promotion (available only to admin user)
user can create promotion
user can delete promotion
user can save promotion
user can set promotion begin date
user can set promotion end date
user can add one or more items to promotion
user can add one or more brand to promotion
user can add one or more category to promotion

Then there are cross-cutting concerns such as authorization (as
described in the first module), logging, persistence and of course DI.

[colaru]

Hi Richard,

I think will be fine if you can add a comment for each service exposed
method (in the services interfaces), describing the behavior for it
(OrderManagementServiceImpl implements OrderManagementService). In
this way will be clean for both what to expect/implement in this
services - and also this information will be displayed in the
generating javadoc:

/**
* View the list of orders from a given date till now. If there is no
order in this period a emty list is retunerd.
*/
public List<Order> viewLastOrders(Date date) {
return null;
}

...

Regards...


You can define some business errors that can be thrown by this

[transmeta01]

Hi Cristian,

I will try to better define and document (javadocs) the service
interfaces. In general you can rely on the user stories for the
implementations.

By "business errors" do you mean the exceptions or the errors
messages?

Richard

[Cristian Olaru]

Hi Richard.

In fact business exceptions (I use a bad name) that are part of the services signatures (I prefer to throw business exception on this level instead returnig null's). Are not runtime exceptions - you will catch them in presentation - are part of our services contract.

Because the interface (presentation) is driven by you, for me the entry point for me are the services (in fact you decide from presentation what services you need to be implemented). So the services layer will do what you want - the user stories will have a reflection in interface (WS) and not directly in the services layer.

So, at this layer we must collaborate for details. Now I can implement and test as I fell.

Regards..

--
Cristian Olaru
weblog: http://olaru.blogspot.com
mobile: 0743163039

[transmeta01]

On Jan 24, 5:02 am, Cristian Olaru <col...@gmail.com> wrote:
> Hi Richard.
>
> In fact business exceptions (I use a bad name) that are part of the services
> signatures (I prefer to throw business exception on this level instead
> returnig null's). Are not runtime exceptions - you will catch them in
> presentation - are part of our services contract.

Actually, the service and business exceptions should propagate up to
the "resource" layer, where a proper HTTP_STATUS_CODE will be included
in the response. The presentation layer know only about which URI to
use to invoke a particular service.

for example, the client would do something like this (for a
registration)

Client request:
PUT /user HTTP1.1
Host: https://classic.com/
User-Agent:
Content-Type: text/json; charset=utf-8
Content-Length: 9090
...

<!-- json serialisation of user data-->
[ {
"username": "joe...@gmail.com"
"password": "hash(password)"
"address": "...."
....ect......
}]

server dispatches to the appropriate handler, extract headers in
necessary, de-serialize json message body and processes it. If
successful server returns :

Server response
HTTP/1.1 201 created
Location: http://classic.com/user/userid
Date: ...
Last-Modified:

...other data is needed here....ect....

This approach allow to expose the service to other type of clients
(i.e not browsers based).

>
> Because the interface (presentation) is driven by you, for me the entry
> point for me are the services (in fact you decide from presentation what
> services you need to be implemented). So the services layer will do what you
> want - the user stories will have a reflection in interface (WS) and not
> directly in the services layer.

The user stories are reflected in the resources they represent. For
example, we have a user resource for a the UserService class,
ect...Look at the resources folder, you should see some definitions of
the resources service. This layer is the entry point. All of these
services and resources are stateless, from end-to-end. Client is
responsible for its own internal state.

This design allows for easier vertical (adding services) and
horizontal (adding more machines) scaling if needed.

When we will clustering, I plan to use a session hashing and store it
in the DB for "load balancing" and moving the actual design to SEDA
style architecture. But will probably happen much later.

>
> So, at this layer we must collaborate for details. Now I can implement and
> test as I fell.

We could a skype video call or a google chat if you like. Let me know
if you need that and when is it a good time for you.

[transmeta01]

SEDA is "Staged Event Driven Architecture" see : http://www.eecs.harvard.edu/~mdw/proj/seda/
for more details.

[Cristian Olaru]

Hi Richard.

Now is fine for me.I already work with this REST style in my job. For me it wasn't unclear the usage of Services layer from GWT. Now I understand that you will not call directly the services but you will make rest calls (with JSON messages) for acceding the backed application. Am I right?


Regards...

[Richard Mutezintare]

Hi Cristian, yes that is correct.