Bob Jake

Excited to see what changes in Spark 3

Noah Gift wrote:

Bob Jake wrote:Curious to see the definition of Pragmatic here. Is this pragmatic process or pragmatic 'bias' results ?

The process is pragmatic here.  The general problem I have seen both an engineering manager and a professor is a lack of "bias for action" to use a phrase they use at Amazon.  How can an individual or organization get past the theoretical and get into solving a solution an efficient and effective way.  For example, maybe using a high level tool like AWS Sagemaker to deploy a machine learning model could be called pragmatic vs rolling your own ML model into production and deploying into manually orchestrated web services.

Great!. Looking forward to read your book.

Curious to see the definition of Pragmatic here. Is this pragmatic process or pragmatic 'bias' results ?

Originally posted by Marc Peabody:

The only major negative consequence I can see with this approach is that potential service clients who discover a service endpoint see the types defined in the request or response and assume that all of these "optional" elements are relevant to the endpoint.

What about just forgetting harmonization altogether? I imagine it would be tremendously frustrating for a client to call two difference services with similar data but in one service a tag is organization while in the other service it is organisation or org or company. It would be terrific to at least keep tag names in harmony.

Forgetting harmonization will be at antithesis to the SOA philosophy. Using multiple schema however poses an interesting problem. While each service is a contract, it will be useful for the domain client to use a single entity representation maybe by utilizing the extended schema (org/organisation/company) alone and not the base representation (as the case might be) or through the transformation at the client layer if multiple external services are providing different representations.

________________________________________________________________________________________________________________________
"In a large organization it is unreasonable to expect total data type harmonization over the entire service inventory - ultimately that would prove counterproductive as it would continually hamper your efforts to evolve your inventory. However you should divide you service inventory into distinct business domains (Domain Inventory Pattern). Within each domain you should try to harmonize common data types. However on a case by case basis you may run into the odd service who's functional context needs to add data that other services are not interested in propagating (but some clients may be interested in)."
________________________________________________________________________________________________________________________

The ideal situation will be to achieve a single canonical representation for the entity (within a distinct business domain) on which general consensus can be agreed to by multiple systems requesting that entity. If the reuse of the canonical is between 1 and 2 only, we will not be achieving the ROI on the investment by the organization. That said, the intent of the SOA organization should be focused on leveraging this exercise to enable all the systems to talk at the canonical model level with the special message interaction treated as an exception or something which that needs to be worked-upon when more evolved canonicals are prepared at regular pre-defined/ planned/ market focused intervals.
________________________________________________________________________________________________________________________
"You may be able to manage some of these additions by only making the core document elements mandatory and making the additions optional (a lot of this depends on whether your web service stack will tolerate "extra" elements and simply ignore them - mitigating the need to update clients that aren't interested in new optional elements of the updated XSD)."
_______________________________________________________________________________________________________________

I would be very interested to know the various alternative ways how the web service stack can be made to tolerate the extra elements. I perceive this as a transformation layer between the canonical and the special message at the service end point for that specific client.
[ December 21, 2008: Message edited by: Remote Reference ]