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

[goran.zugic@semantion.com]

Monica,

Please see my responses below.

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.

JBI is a JAVA-based technical specification. It is an additional layer on top of J2EE. It can be used to implement some FERA-based SOA Gateway functions and similar SOA components functions but it is not an open standard technology neutral specification.

> 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?

FERA-based SOA is a loosely coupled architecture and each component of FERA-based SOA fully supports loose coupling. In fact, loose coupling along with the semantic integration are among the basic principles of FERA

> 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).

FERA-based SOA uses and recognizes the Agent Framework as one of architectural components. We recommend the use of agents when specific activities can be fully automated without human interactions, or when results of human and systems interactions need to be reconciled according to the rules between federated entities within the timeframe shorter than the humans can do by themselves. FERA-based SOA does not dictate its use at all nor it depends on Agent Framework. Again, FERA based SOA is a loosely coupled architecture which architectural components can be selected in any combination needed to support a specific process deployment and execution.

> 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.

Let us discuss it. Please let me know if you have any specific questions or comments.

> 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.

This is what you said

"...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...."

and that is what FERA-based SOA Information Model and SOA Collaboration Semantics provide: a computable process definition, executed and monitored in SOA Federation with additional support for business transaction patterns, QoS and other capabilities based on SOA IM information generated during the process modeling and collected during the process execution.

> 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).

Agree. And again SOA IM and SOA CS provide support for the business transaction patterns, the expectations of the parties for QoS, etc.

> 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.

No, an event is not a message. In SOA IM and SOA CS, each event has a trigger and one or more actions. A trigger creates (triggers) an event while actions represent event's consequence(s). You can predict events in modeling time (e.g. specify the messages and/or conditions that can trigger them). You can also cluster events to impose process specific synchronizations, since events in FERA-based SOA can go through several stages of life, and can synchronize their life cycles.

> 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.

Different process support solutions/technologies come and go. Service is a  great idea and concept that have become a reality. FERA-based SOA fully supports process definitions deployments as services. However, if you deploy some activities using something else it is also supported but in that case if the communication protocol and an invocation mechanism for that activity is not open standard-based it will not guarantee fully open standard-based system. In FERA-based SOA, each activity and decision has inputs and outputs. Processing of inputs can be defined (e.g. inputs can be single instance, batch, mandatory or optional for service to proceed, version controlled, etc.). The logic of processing the service and its execution environment in FERA-based SOA are not specified, just the roles supporting them, communications of requests, inputs and outputs  to and from these services. As I said, it is a loosely coupled environment. All of this is specified in SOA IM and SOA CS.

> 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.

Technology has been advanced significantly and performance and flexibility of systems depend on its architecture and design.
Properly architectured and designed systems will meet today's business requirements. Unfortunately, there are many architects in IT field today that should be kept far away from it. In any case, advances in the field of SOI (Service Oriented Infrastructure) point to the solutions that are conceptually compatible with FERA-based SOA, whereby resource managers and resource requests can be fully semantically integrated and incorporated in the spectrum of built-in services or  executed using agent based frameworks.

 

> 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.

Let us discuss it. Broader context and more details are needed to discuss needs and consequences of both inside and outside firewall web services deployments. I would appreciate if Jacques can share with us his experience with auto industry challenges.

> 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.
>

In SOA IM triggers are associated with events only. They trigger (create) an event which consequence is one or more actions. Activity is performing a value added transformation of inputs into outputs, when the conditions for its invocation are met. The fact that an activity has reached a successful output delivery may be an event. SO can be the fact that it is failing to reach its desired output availability time (SLA driven). Events signify the points in time that the process may find of particular interest to validate the progress, assess changes in conditions, synchronize activities, etc. That is why in FERA-based SOA, events are associated with activities (e.g. statuses of their inputs and outputs), but can also be triggered purely by various granularity metrics reaching some values,  or other execution conditions that are not necessarily tied to a single activity or process thread.

The best way to fully understand FERA-based SOA is to read FERA-based SOA architectural spec documents available in ebSOA TC document repository. Please let me know if you do not have access to it and I will send you 
Semantion links to these documents.

>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.
>
>