If you have two different services that expose an entity called
"customer", how do you ensure that both services expose the same
schema type to represent this thing called "customer"? When the next
developer comes along that needs to implement a service that exposes
an entity called "customer", how do you ensure that this third service
also uses the same schema type to represent this thing called
"customer"?

I understand your perspective and your preference in using Java to
define your interfaces, but the issue is that when a consuming
application retrieves the service interface, it gets a WSDL with
schema declarations, not a Java interface.

Even though you separate the Java interface from its implementation,
you're still using a code-first development model.

Anne

On 6/12/07, Jarek Kucypera <[EMAIL PROTECTED]> wrote:
Anne Thomas Manes wrote:

> If your goal is point-to-point integration between a single client and
> server, then the code-first development model is fine. But if your
> goal is to implement a service-oriented system, enable reuse of
> capabilities, reduce redundancy, and increase flexibility and agility,
> then the code-first development model is a bad practice.

Actually we used contract first approach, but it just happened, that
we could afford to write the contract in Java.

> Service-oriented systems require governance of data types and
> semantics. I'm sure you've noticed that if you use the code-first
> approach, then Axis will generate a unique set of types and namespaces
> for your application. Proliferation of schema types will make reuse
> extremely challenging, resulting in reduced flexibility and agility,
> and a complete failure of a SOA initiative.


As we wrote separate interface layer, we could give (and we gave)
descriptive names and namespaces, not reflecting  the guts of our apps.
We just used java instead of wsdl to write interfaces to our apps.

J.K.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to