You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Yuhichi Nakamura <NA...@jp.ibm.com> on 2000/12/28 07:07:43 UTC
[Axis Gen] Comments on Design Doc.
I am still not sure if we should produce such detailed architecture design.
However, it is worthwhile to have some agreements on basic notions
described
in Section 3. Here are my comments.
p.s. James, I just took a look at yours. I will comment on it later.
Overall
- I would like to use terminology provided by XP as much as possible.
- I would like you to distinguish what are agreed, and what are just
your thoughts.
3.2 Object Structure ...
-Message is OK. It would be called Envelope instead.
-We may need a global entity like AxisContext, but I have no idea on
usecase.
-TranposrtContext seems too specific. We may use MessageContext as
an abstaction. In addition, we may need SessionContext. MessageContext
has an information related to a "single" message path. I assume that
request/response is comprised of two message paths. In that case,
we may need SessionContext to share information between request
and response message path.
3.3 Component Overview
- Are you claiming that all entities (3.3.2-3.3.13) are Chainable? Which
are
/are not Chainable?
- Why do you need Chain as tangible object? It can be embedded in
ChainContainer as a Chain object or just a Vector of Handlers.
Chain can be encapsulated within ChainContainer.
- In terms of SOAP spec, Header Hanlder and Body Handler might be
distinguished because different fault exceptions are thrown by them.
- As we are discussing in other mails, Router is not a part of
Registry, I think. (See our TRLSOAP)
- Dispatcher is ambiguous. It should be RPCHandler or something.
- TransportSender/Listener seems to specialized for one way messaging.
How do they work for request/response?
- Should we specify Serializer/Deserializer/Cannonicalizer here? To me,
they are components used in TransportSender/Listener.
- Why do you need ChainableRegistry here? Isn't is a portion of
ServiceRegistry?
In summary, I prefer to use the following terms:
ChainContainer, HeaderHandler, BodyHandler, Router, RPCHandler,
TransportListener, TransportSender, ServiceRegistry
More comments will be posted later.
Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413
From: Yuhichi Nakamura/Japan/IBM@IBMJP on 2000/12/27 13:32
Please respond to soap-dev@xml.apache.org
To: soap-dev@xml.apache.org
cc:
Subject: [Axis Gen] How to Proceed?
Axis folks,
I just read through the design document placed at the following URL:
http://www.soap-wrc.com/axis/axis_arch_overview_v03.zip
Then, I came up with a question like:
Should we produce a complete design document before the actual
developement?
At F2F, we agreed that we should have design discussion first,
reach an agreement on an architecture design, then start implementation
assigning some modules to someone. I am not sure that this is the best
way to proceed Axis project. To me, even design discussion seems to
last forever!
TRLSOAP implements some of key features discussed here, and we
want to improve it soon. Should we wait for the complete design?
Maybe I am concerned that nothing is implemented, but
bunchs of documents are/will be produced. Is there someone
who is implementing the design?
There are at least two ways to proceed this project:
1. Complete a design doc., then implement it (as we are doing now)
2. Start from a functional prototype (such as Idooxoap and TRLSOAP)
*Apache SOAP V1/2 took the second approach.
Anyway, I am worring about the slow progress of this project.
Regards,
Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413
RE: [Axis Gen] Comments on Design Doc.
Posted by James Snell <js...@lemoorenet.com>.
Yuhichi,
I think I can speak for Steve as well as myself in saying that we both agree
that the architecture overview is bit more complex than it really needs to
be, and we're working on simplifying it now. The finished product will
include ideas from both the doc Steve produced (which was based on notes he
took at the face to face in Washington and the document I produced which was
basically intended at offering amendments to Steve's rendition. We plan on
pinging the group for discussion and consensus on architecture once all of
the key members have returned and then moving forward on implementation.
- James
-----Original Message-----
From: Yuhichi Nakamura [mailto:NAKAMURY@jp.ibm.com]
Sent: Wednesday, December 27, 2000 10:08 PM
To: soap-dev@xml.apache.org
Subject: [Axis Gen] Comments on Design Doc.
I am still not sure if we should produce such detailed architecture design.
However, it is worthwhile to have some agreements on basic notions
described
in Section 3. Here are my comments.
p.s. James, I just took a look at yours. I will comment on it later.
Overall
- I would like to use terminology provided by XP as much as possible.
- I would like you to distinguish what are agreed, and what are just
your thoughts.
3.2 Object Structure ...
-Message is OK. It would be called Envelope instead.
-We may need a global entity like AxisContext, but I have no idea on
usecase.
-TranposrtContext seems too specific. We may use MessageContext as
an abstaction. In addition, we may need SessionContext. MessageContext
has an information related to a "single" message path. I assume that
request/response is comprised of two message paths. In that case,
we may need SessionContext to share information between request
and response message path.
3.3 Component Overview
- Are you claiming that all entities (3.3.2-3.3.13) are Chainable? Which
are
/are not Chainable?
- Why do you need Chain as tangible object? It can be embedded in
ChainContainer as a Chain object or just a Vector of Handlers.
Chain can be encapsulated within ChainContainer.
- In terms of SOAP spec, Header Hanlder and Body Handler might be
distinguished because different fault exceptions are thrown by them.
- As we are discussing in other mails, Router is not a part of
Registry, I think. (See our TRLSOAP)
- Dispatcher is ambiguous. It should be RPCHandler or something.
- TransportSender/Listener seems to specialized for one way messaging.
How do they work for request/response?
- Should we specify Serializer/Deserializer/Cannonicalizer here? To me,
they are components used in TransportSender/Listener.
- Why do you need ChainableRegistry here? Isn't is a portion of
ServiceRegistry?
In summary, I prefer to use the following terms:
ChainContainer, HeaderHandler, BodyHandler, Router, RPCHandler,
TransportListener, TransportSender, ServiceRegistry
More comments will be posted later.
Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413
From: Yuhichi Nakamura/Japan/IBM@IBMJP on 2000/12/27 13:32
Please respond to soap-dev@xml.apache.org
To: soap-dev@xml.apache.org
cc:
Subject: [Axis Gen] How to Proceed?
Axis folks,
I just read through the design document placed at the following URL:
http://www.soap-wrc.com/axis/axis_arch_overview_v03.zip
Then, I came up with a question like:
Should we produce a complete design document before the actual
developement?
At F2F, we agreed that we should have design discussion first,
reach an agreement on an architecture design, then start implementation
assigning some modules to someone. I am not sure that this is the best
way to proceed Axis project. To me, even design discussion seems to
last forever!
TRLSOAP implements some of key features discussed here, and we
want to improve it soon. Should we wait for the complete design?
Maybe I am concerned that nothing is implemented, but
bunchs of documents are/will be produced. Is there someone
who is implementing the design?
There are at least two ways to proceed this project:
1. Complete a design doc., then implement it (as we are doing now)
2. Start from a functional prototype (such as Idooxoap and TRLSOAP)
*Apache SOAP V1/2 took the second approach.
Anyway, I am worring about the slow progress of this project.
Regards,
Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413
RE: [Axis Gen] Comments on Design Doc.
Posted by James Snell <js...@lemoorenet.com>.
Yuhichi,
I think I can speak for Steve as well as myself in saying that we both agree
that the architecture overview is bit more complex than it really needs to
be, and we're working on simplifying it now. The finished product will
include ideas from both the doc Steve produced (which was based on notes he
took at the face to face in Washington and the document I produced which was
basically intended at offering amendments to Steve's rendition. We plan on
pinging the group for discussion and consensus on architecture once all of
the key members have returned and then moving forward on implementation.
- James
-----Original Message-----
From: Yuhichi Nakamura [mailto:NAKAMURY@jp.ibm.com]
Sent: Wednesday, December 27, 2000 10:08 PM
To: soap-dev@xml.apache.org
Subject: [Axis Gen] Comments on Design Doc.
I am still not sure if we should produce such detailed architecture design.
However, it is worthwhile to have some agreements on basic notions
described
in Section 3. Here are my comments.
p.s. James, I just took a look at yours. I will comment on it later.
Overall
- I would like to use terminology provided by XP as much as possible.
- I would like you to distinguish what are agreed, and what are just
your thoughts.
3.2 Object Structure ...
-Message is OK. It would be called Envelope instead.
-We may need a global entity like AxisContext, but I have no idea on
usecase.
-TranposrtContext seems too specific. We may use MessageContext as
an abstaction. In addition, we may need SessionContext. MessageContext
has an information related to a "single" message path. I assume that
request/response is comprised of two message paths. In that case,
we may need SessionContext to share information between request
and response message path.
3.3 Component Overview
- Are you claiming that all entities (3.3.2-3.3.13) are Chainable? Which
are
/are not Chainable?
- Why do you need Chain as tangible object? It can be embedded in
ChainContainer as a Chain object or just a Vector of Handlers.
Chain can be encapsulated within ChainContainer.
- In terms of SOAP spec, Header Hanlder and Body Handler might be
distinguished because different fault exceptions are thrown by them.
- As we are discussing in other mails, Router is not a part of
Registry, I think. (See our TRLSOAP)
- Dispatcher is ambiguous. It should be RPCHandler or something.
- TransportSender/Listener seems to specialized for one way messaging.
How do they work for request/response?
- Should we specify Serializer/Deserializer/Cannonicalizer here? To me,
they are components used in TransportSender/Listener.
- Why do you need ChainableRegistry here? Isn't is a portion of
ServiceRegistry?
In summary, I prefer to use the following terms:
ChainContainer, HeaderHandler, BodyHandler, Router, RPCHandler,
TransportListener, TransportSender, ServiceRegistry
More comments will be posted later.
Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413
From: Yuhichi Nakamura/Japan/IBM@IBMJP on 2000/12/27 13:32
Please respond to soap-dev@xml.apache.org
To: soap-dev@xml.apache.org
cc:
Subject: [Axis Gen] How to Proceed?
Axis folks,
I just read through the design document placed at the following URL:
http://www.soap-wrc.com/axis/axis_arch_overview_v03.zip
Then, I came up with a question like:
Should we produce a complete design document before the actual
developement?
At F2F, we agreed that we should have design discussion first,
reach an agreement on an architecture design, then start implementation
assigning some modules to someone. I am not sure that this is the best
way to proceed Axis project. To me, even design discussion seems to
last forever!
TRLSOAP implements some of key features discussed here, and we
want to improve it soon. Should we wait for the complete design?
Maybe I am concerned that nothing is implemented, but
bunchs of documents are/will be produced. Is there someone
who is implementing the design?
There are at least two ways to proceed this project:
1. Complete a design doc., then implement it (as we are doing now)
2. Start from a functional prototype (such as Idooxoap and TRLSOAP)
*Apache SOAP V1/2 took the second approach.
Anyway, I am worring about the slow progress of this project.
Regards,
Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413