Re: [ebsoa] [ebsoa]: FW: the Versatile B2B gateway

[goran.zugic@semantion.com]

Monica,

I am already in the pre-holiday mood. I am getting even more excited about the discussion we are having. Thank you very much for your detailed comments and questions. I will get back to you next week.

Have a great holiday everybody and I cannot wait to continue our discussion next week.

Goran

>-----Original Message-----
>From: Monica J Martin [mailto:Monica.Martin@Sun.COM]
>Sent: Friday, December 23, 2005 01:25 PM
>To: goran.zugic@semantion.com
>Cc: 'Hamid Ben Malek', 'Jacques Durand', 'John Hardin', vasco.drecun@cpd-associates.com
>Subject: Re: [ebsoa] [ebsoa]: FW: the Versatile B2B gateway
>
>
>>zugic: Jacques and Hamid,
>>
>>This is our inital response with FERA-based SOA related feedback and comments. If additional comments are received from ebSOA TC editors they will be sent to you. Please let me know if you want to discuss further on this.
>>
>>Regards,
>>Goran
>>
>Goran, thanks for the details. A few points of clarification/insight:
>
> 1. See previous comments on JSR-208. There are standards in this domain.
> 2. Allowing federation, process, policy and other capabilities to be
> available and effectively used but loosely coupled to the
> infrastructure is very important. Just to clarify, does the
> Federation Manager support such loose coupling?
> 3. In an SOC conference last week, there was a great deal of
> discussion surrounding different mechanisms to realize SOA. An
> agent framework is one design and implementation choice (this
> recognizes its potential value but not dictating its use).
> 4. For what you term SOA Federation, we should discuss the coupling
> here and the assumptions based on existing technical realities and
> constraints in many businesses today.
> 5. We should differentiate/clarify what is meant by execution. At
> times, many assume process language or definition = execution.
> This fails to recognize that a process definition is computable
> and processable, and that what it provides is a monitoring
> baseline that evidences the expectations of the parties involved.
> For example, for WS-BPEL at executable process includes many
> private details and process specifics that help drive a process
> engine. It also assumes that most often (if not all the time) that
> messages are service-enabled in the context of web services. In
> important cases, those assumptions fail to support the
> collaborative domain. However, the Versatile Gateway pattern is
> underlying the process domain, so this information is outside of
> the scope of this pattern.
> 6. When you venture into the discussion of "contains more data needed
> to process the request", we really should recognize what provides
> the true value add for the collaborative domain - the business
> transaction patterns, the expectations of the parties for QoS,
> document security, and the substantive differences between
> business messages and business signals (rather than transport
> messages).
> 7. Actually, Goran, I would need to know the authority and use case
> that indicates that an event carries a business document. In
> making this request, I assume that an event != a message.
> 8. Not all process definitions are deployed as services unless we
> take quite a broad definition of service. This may be the case in
> your response.
> 9. In key domains of which I am aware, assuming that the process
> logic, definitions and other service functions are dynamically
> available and used operationally from a Registery may fail to meet
> that domains' requirements for performance or flexibility. They
> may also lack the resources to enable them. Don't get me wrong,
> the Registry provides great value; I highly support its use. My
> comments surround the practical application given the constraints
> of the domains served.
> 10. Many eBusiness experts may wish to comment on web services
> deployment outside of the firewall. Jacques Durand could speak to
> hands on experience with those challenges for the automotive
> industry.
> 11. For "All these messages are received or sent through the Gateway.
> When the Federation Manager receives any of these messages it
> checks the type of the document(s) attached to the message and
> verifies if any of the documents is an input for an activity, a
> decision or a trigger that creates an event. Each collaborative
> (business) process has one or more collaborative process flows."
> A trigger may be associated with an activity but I still tend to
> differ that the activity itself is the trigger. They may be
> associated. To me the triggering or enabling condition makes the
> environment either capable of taking a specific action or triggers
> it. We've had fairly detailed discussions in ebBP about the
> context and domain specific aspects of what conditions, events and
> triggering mechanisms that may exist, and whether they actually
> are visible as shared detail. I'll not get into that discussion here.
>
>Thanks again for sharing your experience and perspectives. I think we
>have quite a way to understand what are the practical applications of
>capabilities in the eBusiness domain and what that infers for and is
>reflected in FERA. Thank you.
>
>