Web Services Architecture F2F Meeting -- 28 July 2003

Attendees

Contents

• Topics
• Summary of Action Items

Scribe: Katia Sycara

<MikeC> Let us go around the room and express hgh level impressions about the current draft document. We want to make sure we have time to discuss the issues that come up

<Chris> did we settle on definition for WS? “machine to machine”

<MikeC> the trout discussion is scheduled for Wed morning

<Roger> separating into models is helpful. Stakeholders have nothing to do with stakeholders but viewpoints. So, some material from stakeholders should be moved earlier (e.g. reliability, semantics). Get rid of the section of stakeholders as a section but keep some of the material.

<Hao> we do not talk about stability in the document just reliability.

<MikeC> do you think there is place in the agenda for this?

<Frank> security/privacy should be part of the agenda.

<MikeC> But security is in the policy model. Let us discuss security and privacy under the policy models section of the agenda.

<Daniel> Issue of conformance is not well addressed. Also, let us more thoroughly cross reference the requirements document.

<Shishir> Is there in scope to talk about a programming model?

<MikeC> we are removed from programming models

<MartinC> no comment

<Doug> I liked the new organization. But, it is very descriptive, does not give architectural choices, no rigorous architectural language.

<Frank> we have wasted much time on trout ponds, e.g. what is WS?

<Mikec> that is why we have trout pond on wed.

<Zulah> from perspective of management,. stakeholders view works well, explaining how the soa model and management model work together. But missing is the deployment model, relationships between deployed elements and life cycle.

<Bryan> table of contents should call out what is normative and what is not

<MikeC> normative and non-normative are interleaved.

<Frank> we need to discuss normative as an issue

<MikeC> let us put on agenda

<Bryan> I thought it was interesting. Things are sort of laid out as patterns. Role perhaps is to do a partially constrained language, and it is how you can introduce narrative. If you want to do must, may, should etc, they should be qualifiers on the links on the diagrams.

<Katia> the current draft is a great improvement over previous ones.

<Hugo> It looks good. Models should be better related. In Reines, we have talked about extracting some of the “language” concepts and putting them in another section, ie description language, choreography language. Separation between abstraction and the realization. In the document, we are talking about rpc, but there is this movement going away from rpc into document oriented process, but we do not say this in the document

<MikeC> something to keep in mind to discuss.

<CrisF> we should say something about document vs rpc. Also, we should be more explicit about what are the things that the people should be paying attention to. The document should be more user-friendly, there is too much info, but nothing that grabs you. Also, we need evolution of web services, why are we doing this? There have been definitions of interface for a long time. There is no mention in the doc of versioning and loose coupling of services.

<Roger> I agree with Hugo’s point about document-oriented style, but it has gone a long way, perhaps too much in this direction.

<Martinc> an architecture should discuss the tradeoffs of doing things different ways. (e.g. rpc vs document oriented)

<MikeC> let us find time to talk into this

<HugoH> we put much independent work in the glossary and need to link better with the wsa document.

<HaoH> need to put more links in the document.

<MikeC> people should point specifically where the editors should put in links.

<Hao> We have automated linking technology that could help.

Scribe: ACTION: Hao to talk to the editors about automated linking technology.

<Bryan> We have a stack from agent into legal entity. In 1.7 the web technologies stack is an overview of web service but hardly needed in the arch document

<Frant> is there anything from tag discussion we need to discuss?

<MikeC> discussion whether resource is a fruitful concept is one such issue. Let us discuss on Wednesday.
... we all want to reach end game in this year. We must have a plan of moving the arch doc forward. We must do it better. We must wrap this up within 6 months. Many strategies: e.g. take more time, or leave trout pond issues unresolved etc.

<Roger> I do not consider an option to do this for the rest of my life. One good strategy is to take stakeholders sections into the main document. It would simplify the task.

<MikeC> But there are some things missing like loose coupling etc

<Roger> the readability is good currently. Stakeholders’ section is not good. Currently stakeholders section content is almost identical to rest of document

<Frank> shredding stakeholders section would be a mistake. Perhaps there is material that could be improved there. The purpose of the section is to represent stakeholders in the architecture.

<MikeC> we have not spent much time in the stakeholders section. We need to talk about the stakeholders section.

<Frank> shredding is not viable. Take security, for example. To answer the question “ does the arch answer security concerns?” you need to dip to different sections.

<Katia> let us clarify the notion of what a stakeholder is vs what a requirement is.

<MikeC> let us put on the agenda.

<Hao> let us add some time since the technology is evolving.

<MikeC> yes, we do need a plan for maintenance of the document

<Hao> how many more f2f?

<MikeC> 2 more.

<ChrisF> I sympathize with Roger’s position. The stakeholders’ section is the section for providing something that is user-related. Frank also has a good point. It could form a thread for the document with everything else sprinkled in. There are also multiple views of the arch, such as styling, e.g formal constraints vs something that must be read by developer.

<Frank> we need more votes, decisions to be made, but also we need editors to work on them. It is possible to meet the deadline.

<Daniel> last call working draft or last call as recommendation?

<MikeC> last call working draft. Point where we feel we have met our requirements.

<Austin> we can get to a last call working draft by time of our mandate. The group will be re-chartered for at least another year to shepherd it to last call recommendation. So, let us work backwards to make a plan with stack of deliverables. We must work smarter to increase documents explanatory power.

<Shasir> lots of text. It would help what is normative.

Scribe: ACTION: Daniel will put together a project plan to cover till end of the year.

<Tom> I d not feel confident about the document. While it is informative, it does not provide enough constraints as an arch to inform me as a consumer of specs by architects. It looks like the web services ARCHITECTURES not one architecture.

<MikeC> analogy is with osi arch, which is not very good for guide to implementation but it is talked in all textbooks etc.

<Tom> there is a lot of work but we need to constrain by removing options. As a consumer, the MUSTs are better for me, the options cost money.

<Daniel> Let us take as example the TOGA-F document produced by OMG. It is a framework with similar goals as ours. Many people (in particular, government and large corporations) consider it as a good normative architecture to follow.

<Bryan> let us find a place in the agenda as to what the architecture is aiming to achieve as an architecture.

<MikeC> let us discuss this during trout on Wedsnday..

<Eric> interested in consistency across the document. Also, expanding the discussion on the stack diagram in 1.7. Need better separation of design time artifacts and execution time artifacts. I am volunteering to look into these. I am in favor of a concrete plan . Look again at primer.

<MikeC> how do we get to a reasonable milestone by 6 months?

<Bryan> I volunteer a contrary position to the notion of cutting scope. I will be ok with cutting scope of the document if we can leave portions for future. Can we take entire piece e.g. one of the models that could be dealt with by other working groups etc. Let us try to find out what we can cut.

<Hugo> we still have a lot of work to do, e.g. security section. Need list of things to do and prioritize them, so we can finish the most important ones. We will have to work in parallel and have small task forces with short deadlines to work in parallel.

<Frank> when we did the requirements, we had critical success factors. Either they are critical or not. If we agreed that something was critical to the success of the architecture, we have not done our job if we have not addressed it.

<DavidB> another possibility to reduce amount of work is to reduce the detail.

<MikeC> let us have Zulah review the management section

<Frank> let me explain the history. The concepts diagram, stakeholders etc come from many sources. Last time it was touched was two f2fs ago from discussions with Hether harvesting information from the MTF document.

<Zulah> I would like to get agreement of what is in and what is out from the document. So we can separate content to go out as a note.

<MikeC> does this reflect the work you folks were doing?

<Zulah> the state of the document is good regarding putting management in context. There are some issues with the content, both large and small issues.

<Frank> big issue of what is being managed. This model does not define what is being managed, but rather what it takes for something to be managed. It is not trying to manage everything either. Two parts, managing web services and also using web services to do management of web services. What is in the document fits those two purposes. The key concept of manageability is the deployed resource (deployed element). Key thing to capture is the relation between something to be managed and the thing itself. Key idea is notion of something actually existing. E.g. a document on a file server or a process that is running; it exists and so it can be managed.

<Zulah> this is a key issue, in management terms it is not clear what it means to manage a WSDL description file, for ex.

<Frank> it may mean for ex. that you need to back it up.you cannot manage something without managing its description

<Zulah> this is a good point. But we do not want to necessarily manage everything that is pointed to by a uri.

<Frank> is there one normative lifecycle?

<Zulah> yes, and we need a deployment model.

<Hao> service is an abstract thing. What do you mean by deployment of a service since a service can be performed by multiple providers?

<MartinC> we need to capture notion of instances, target resource vs multiple interfaces. We have things, they have operational interfaces, we also have management interfaces. Deployed things are instances of services.

<Hao> instance of a service itself can be abstract and be provided by multiple agents.

<Roger> I do not understand difference between a lifecycle and a choreography.

<Frank> this isa resource view of web services.

<MikeC> we need to understand Zulah’s world.

<Zulah> foe every resource we are managing we need to know its lifecycle.
... manageability interface: a contract between a service provider and a management system.

<Frank> I agree, the word “metric” is misused in the document

<Zulah> one critical thing missing is policy management. E.g. quality of service or distributed services, what is the access model for these?

<ChrisF> a deployed service is within a container within which it is deployed.

<Hao> service and service management are two different services.. We do not care how service management is implemented.

<Zulah> we do have to manage things that are in different IT silos.

<Frank> we agreed that manageability was a critical success factor for the architecture. We really have to address that systems that conform to the architecture should be manageable. The management model reuses a lot of the concepts in the rest of the architecture to capture meta-object relationship.

<Katia> proposal to produce a picture and also articulate set of tradeoffs for different decisions regarding the management model

Scribe: ACTION: Zulah will work with Frank and Hao to produce a management document by next f2f that has pictures, concepts and relationships, design tradeoffs, and stakeholders’ view.

<Chris> there is nothing in wsdl right now that distinguishes between static design time and execution time. Is the combination of management interface and business interface a service so that we describe in wsdl?

<Roger> we are having this confusion because we have not clarified what service is.

<Zulah> all we need is a contract between a deployed instance of the service (a managed object) and the management system. This is done through a management service interface that is described via wsdl (ie it can be discovered etc).

<Bryan> Management Interface and Business Interface have difference in semantics. There is a distinction in type. We need a mechanism to talk about this distinction.

<Crhis> I agree with Bryan.

<MartinC> they distinguish the things that are managed from the thing that manages them, so recursion stops. Which container they are deployed in, is not an issue. Sometimes you want all of them to have generic management interface.

<CrhisF> previously, in doing mgt we have been dealing with real things, objects, that have well architected interface within a real environment. Now, we are talking about web services in the abstract, having many objects scattered along different machines etc, so it is more complicated.

<Hugo> it is important to have the work of the MTF as a working note. Which of the work that the MTF has done should be published as a note?

<Zulah> I should work with Heather to see what she needs. We do need to be aligned with the wsdom TC.

Scribe: ACTION: Zulah will work with Heather on the Note capturing the MTF work.

Afternoon Session

<Mike> discuss MOM 2.3.1

<Katia> What does MEP is the life cycle mean? 2.3.1.5.2

<Francis> Happy to remove it.

<David> how to describe MEP, the instance of MEP, an actual ME.

<Group> Wide discussion about issues.

<Bryan> whether MEP stay at the level of agent. At WSDL level.

<Mike> people have have

<Francis> There is an inform understanding of MEP. It is atomic, where

<Katia> Simple MEP is expressed in SOAP.

<Group> looking at the text of MEP.

<Resolution> Definition is ok.

<Mike> SOAP view, WSDL view and choreography view. Add a new para to
... Ground choreography on MEPs?

<Martin> choreography are MEPs. Debates on both ways.

<Bryan> Having problem with More complex applications require multiple,

<Group> did not agree.

<Francis> should discuss the relationships.

<Hao> should we discuss syn or asyn?

<Roger> already in the text.

<Mike> should make it normative.

<Hugo> Make def consistent with the explanation.

<Francis> the def of MEP can mean anything.

<Mike> make it simplest. Complex MEP is choreography.

<David> it is fine.

<Martin> which one is complex and which one is simple.

<David> a longer sequence of messaging.

<Katia> more than two party MEP is complex. More than req/response is

<Chris> Against a message exchange pattern may be expressed in a choreography

<Eric> what is the difference.

<Chris> A pattern is a pattern. A choreography is an instance of pattern. A

<Dave> The difference of MEP is at various level we think about. PO service.

<Mike> How to submit PO is choreography.

<David> confused by what Chris said. A MEP is a pattern of exchanging

<Hao> Are those MEPs: Request/Response (yes)

<Chris> Compose choreography types in terms of those little types. Instance

<Francis> MEPs are atoms of exchange. Choreography are patterns of using

<Danel> Agree with Chris. Not sure about what Francis talked about. By

<Paul> need to associate MEPs with levels. So one can bind an MEP with

<Martin> a ver complex issue. What is atomic. What does SOAP or WSDL mean? If

<Chris> pattern is generic. It has not application domain. You provide an

<Eric> it has to be kept at SOAP level.

<Dave> no progress has been made on choreography. take look at real-world

<Byron> MEPs should be restricted at the agent level. Choreography is between

<Roger> is a->b->c->a an MEP?

<Chirs> no.

<Katia> we do have a confusing about def of MEP. Propose an MEP may be used

<Hugo> Form a MEP task force.

<David> support the application domain as a distinction factor.

<Chris> agree with that overall pattern cannot be described in terms of the

<Mike> Vote on the def of MEP at 2.3.1.5.1.

<Chris> avoid application semantics. All agreed.
... the a->b->c->a thing is choreography.

Scribe: ACTION: Katia, David, Bryan, Francis, Matin, Danel, Chris. Get a def of MEP.

<exchange> passed.

<Katia> a MEP may be bound to a protocol.

Scribe: ACTION: the chair needs to record " MEP is only supported by infrastructures while chronography is supported by application".

<Mike> MOM will be the focus for the next couple of months.

<Francis> worries about intermediary.

<Mike> does not consider intermediary is a serious issue.

<Francis> introduced SOM.

<Danel> how SOM relates to SOA? Relate SOA with WSA.

<Roger> the def of service is not what WSDL service is. This is not what we

<WSDL> service is a collection of endpoints.

<Mike> cross reference with WSDL.

<Martin> shows SOAP 1.2 binding and WSDL 1.2 service diagram.

<Chris> code-generation is significant from IBM's point of view. You don't

<Group> general discussion about Martin's diagram. Try to map both diagrams.

<Chirs> Martin's diagram may not be inconsistent with the WSA's diagram. Is

<Martin> that is service element in WSDL so they are different.

<David> that service box should really be service.

<Martin> what do different interfaces mean?

<Katia> different endpoints have different protocols.

<David> they all implement the same abstract service.

<Roger> what is relationship of service, tasks and action?

<Francis> not sure.
... how MOM relates with SOM. Will explain what SuperV is.
... MOM and SOM are showing at two different level of abstraction. In

Scribe: ACTION: Frank will produce a diagram and text to explain how MOM and

Summary of Action Items