tag:blogger.com,1999:blog-76407983191905727522024-03-13T20:13:43.288+01:00SOA is not a disease!SOA can deliver strategic value to companies willing to change (part of) their enterprise, not just their IT systems! Many companies however have tried and failed delivering SOA with the promised reduced IT burden and ROI. Some companies are even treating SOA like a disease. This is not fair. SOA is a way of thinking applied to supporting tools and not a tool on itself.
I hope this collective set of topics will help companies decide whether this SOA thing is blessing or burden.Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.comBlogger55125tag:blogger.com,1999:blog-7640798319190572752.post-56673975981141339622012-12-31T17:47:00.000+01:002013-01-02T12:39:01.560+01:00Some thoughts on service naming / service capability naming conventions (2/2)<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" trbidi="on">
This post was created due to a few questions on this topic in my initial post on <a href="http://soa-ind.blogspot.co.uk/2009/12/some-thoughts-on-service-naming-service.html" target="_blank">service and service capability naming</a> in 2009. Elena's questions revolved around concrete service naming (endpoint naming). I had promised Elena a month ago that I would come back to this topic once I could sort out my time so here goes....<br />
<br />
<h3>
<b>Abstract approach first:</b></h3>
Service and service capability naming is driven by the context (purpose) of the service or capability. The service defines the context itself and the capabilities define what you can do within that context.<br />
<br />
By this definition, no relation exists between the service or capability name and the transport, end point type, parameters passed etc.<br />
<br />
This post conveys the message that regardless of the implementation, transport etc. the name of the service or capability is not affected.<br />
<br />
The example in the previous post used, was the Order (entity) service. The 'Order' context defines the actual order service name: 'Order'-Service.<br />
<br />
Within the OrderService, a number of example capabilities exist:<br />
- create<br />
- get (or getDetails depending on you naming conventions)<br />
- getHeader<br />
- update<br />
- updateShippingAddress<br />
- cancel (cancels a running order)<br />
- search<br />
<br />
This order service apparently has 6 capabilities, following the CRUD approach which is common for entity services. One more #7 capability exists and is used to find orders (Order::search). (<span style="font-size: xx-small;">Note that the :: notation was borrowed from C++.)</span><br />
<br />
In an object oriented language like C++, method overloading can be used to have several versions of the same capability.<br />
<br />
As an example, let's explore the search capability a bit more: the Order::search is defined as:<br />
<b>Description:</b> Search for orders and return a list of orderIDs which adhere to the search criteria.<br />
<b>Input:</b> various (combinations of) search criteria<br />
<b>Output:</b> List of order IDs (list can have 0, one or more results)<br />
<br />
Let's take a closer look at this contract:<br />
- The <i>context </i>is <u><i>always the same</i></u> for all capabilities: <i>Order</i>.<br />
- The <i>purpose </i>of the capability is <i>searching </i>for orders; this is <i><u>always the same</u></i> regardless of how I search (which parameters used).<br />
- The <i>result </i>of the call is <u><i>always the same</i></u>: a list of orderIDs is returned<br />
<br />
So if all of the above are the same, the only one factor that might change is the way I search for orders (or in technology speak: which parameters I use).<br />
<br />
As an example, I can search for orders based on:<br />
- address<br />
- customer lastname/city/DoB<br />
- customer ID.<br />
This means I can search using one of three ways for finding search results.<br />
<br />
In C++ this can be solved by method overloading which might allow me to define the following methods (please ignore the syntax I'm just trying to convey a message here):<br />
- <span style="font-family: Courier New, Courier, monospace;">Order::search(geoAddress)</span><br />
- <span style="font-family: Courier New, Courier, monospace;">Order::search(Lastname, City, DoB)</span><br />
- <span style="font-family: Courier New, Courier, monospace;">Order::search(customerID)</span><br />
<br />
As you can see in the example above, in C++, although different parameters are used in the method signature, the actual name of the operation does not change. The reason is because context, purpose and result are the same; we're just using different search criteria.<br />
<br />
In Web services, the same applies: if context, purpose and result are the same, there is no need to change the service capability name. The concept of method overloading does not exist in web services. This means that, in order to achieve a capability name that does not change, another solution must be found.<br />
<br />
A significant difference between C++ and Web services exists (between most OO languages and Web services in general):<br />
- C++ uses parameters in the method signature<br />
- a web service only has one input parameter: the input <b>document </b><br />
<br />
<br />
<br />
An example that shows how a capability only has one input document:<br />
<blockquote class="tr_bq">
<span style="color: #0b5394;"><porttype name="OrderService"></span><br />
<span style="color: #0b5394;"> <operation name="search"></span><br />
<span style="color: #0b5394;"> <input message="ns0:searchCriteria" /></span><br />
<span style="color: #0b5394;"> <output message="ns0:orders"></span><br />
<span style="color: #0b5394;"> </output> </operation></span></blockquote>
</div>
</div>
</div>
</div>
In practice we never talk about input/output parameters when we talk about web services. Instead, we talk about input and output documents.
The input/output documents can be complex XML structures and this means that we can still have some flexibility in this area: we can define an input document that allows to take in complex XML search criteria.<br />
<br />
<h3>
Concrete approach:</h3>
<br />
Following the abstract approach, whenever an actual service is built, the service can be used in various scenarios and implementations.<br />
<br />
One of Elena's questions was whether or not there would be one WSDL per service or per service capability? I'm personally fond of one WSDL per service and would only break up if there are size/readability issues or in case there is a security need to now show specific operations in certain scenarios. As a consequence, if you ask me the first generic implementation of a WSDL would be to have all capabilities listed as operations in the WSDL document. So one OrderService.wsdl and multiple operations in the same service. The reason why I'm so fond of this approach is because it reflects the context definition of the abstract approach so beautifully.<br />
<br />
Now let's try and solve the method overloading challenge from the first part of this post. If we create an input document for the search capability that looks like this:<br />
<blockquote class="tr_bq">
<span style="color: #0b5394;"> <xs:complexType name="searchCriteriaType"></span><br />
<span style="color: #0b5394;"> <xs:sequence></span><br />
<span style="color: #0b5394;"> <xs:element name="Address" minOccurs="0"></span><br />
<span style="color: #0b5394;"> <xs:complexType></span><br />
<span style="color: #0b5394;"> <xs:sequence></span><br />
<span style="color: #0b5394;"> <xs:element name="StreetName"/></span><br />
<span style="color: #0b5394;"> <xs:element name="HouseNumber"/></span><br />
<span style="color: #0b5394;"> <xs:element name="City"/></span><br />
<span style="color: #0b5394;"> <xs:element name="Country"/></span><br />
<span style="color: #0b5394;"> </xs:sequence></span><br />
<span style="color: #0b5394;"> </xs:complexType></span><br />
<span style="color: #0b5394;"> </xs:element></span><br />
<span style="color: #0b5394;"> <xs:element name="NameAddressDOB" minOccurs="0"></span><br />
<span style="color: #0b5394;"> <xs:complexType></span><br />
<span style="color: #0b5394;"> <xs:sequence></span><br />
<span style="color: #0b5394;"> <xs:element name="CustomerLastName"/></span><br />
<span style="color: #0b5394;"> <xs:element name="DateOfBirth"/></span><br />
<span style="color: #0b5394;"> <xs:element name="City"/></span><br />
<span style="color: #0b5394;"> </xs:sequence></span><br />
<span style="color: #0b5394;"> </xs:complexType></span><br />
<span style="color: #0b5394;"> </xs:element></span><br />
<span style="color: #0b5394;"> <xs:element name="customerID" minOccurs="0"/></span><br />
<span style="color: #0b5394;"> </xs:sequence></span><br />
<span style="color: #0b5394;"> </xs:complexType></span></blockquote>
<br />
we can use any of the three listed possible ways of searching. By adding more restrictions to the XML (not a fan!) you might for example indicate that only one of the three search criteria can be used in any given call).<br />
<br />
<h4>
Different service platform to implement a service</h4>
<br />
A service inventory can be comprised of hundreds or more services and since service-orientation allows for flexible choices regarding vendor platform etc. can allow for quite a heterogeneous environment. Sometimes by adding or removing new vendor technologies (remember this is like gardening; the service inventory is not a static thing; it grows in certain areas at certain times of the year, and shrinks in others) the implementation of certain functionality might be moved around. If the name of the service would depend on the vendor platform, this would mean that when changing the platform, the service had to be renames with all the cascading consequences (repository retire old service, create new service, fix dependencies etc). Generally speaking a bad idea. The better approach would be to leave the service and capability name the same and use a versioning naming scheme to solve this problem. The new implemented version would not have a major version increase if the service remains compatible (assumed here) and only a limited cascading effect would be noticed (regression testing mainly).<br />
<br />
<b>Conclusion: </b>do not couple the name of a service or service capability to the platform or vendor stack on which the service is implemented.<br />
<br />
<h4>
Different language to implement a service</h4>
<br />
Similar to the previous one if, by coincidence, a particular programming language is used to implement a service, this should not influence the name of the service (capability). Sometimes specific tasks are solve easier in one language than in another for any number of reasons, and the context, purpose and result of the call does not change, so why rename it? Conversely, a service (capability) can be comprised of more than one component and not all of them need to be written in the same language (ie. combination of J# and C#). If the language used to implement a service really mattered, this would be a nice naming challenge...<br />
<br />
<b>Conclusion: </b>do not couple the name of a service or service capability to the language or component technology used.<br />
<br />
<br />
<h4 style="text-align: left;">
<b>Different transport used on a service capability</b></h4>
<br />
Assume that we have a web service implemented using SOAP 1.2. Typically the message is sent on the HTTP transport, but for some capabilities (or for all) we can allow for a JMS based transport if needed. This means that the one service capability can have multiple transports. It does not make any sense at all to create two capabilities just for this purpose. Modern middleware allows different end points on different transports almost seamlessly. It's the same code that is executed, it is just accessed in another way. This does not at all justify a different name. In the service repository, one might find two transport references with this service: "HTTP, JMS" but that's all - the service capability is and remains the same.<br />
<br />
<b>Conclusion: </b>do not couple the name of a service or service capability to the transport technology used.<br />
<br />
<h4 style="text-align: left;">
Different interface implementation</h4>
<br />
Assume we have a web service implemented using SOAP. Additionally a REST interface is required. Does that mean I get a searchREST and a searchSOAP capability? The answer is a clear NO! Reason for this is again that it's not a different capability; it is just accessed in a different way. It is still the same context, purpose and result. When looking at how we access these interfaces, these are clearly distinctly different and can be easily identified from each other just by looking a the message contents; no need to create a different capability name for that.<br />
<br />
<b>Conclusion: </b>do not couple the name of a service or service capability to the interface implementation used.<br />
<div>
<br /></div>
<br />
<h4 style="text-align: left;">
Different underlying database</h4>
<br />
Already addressed in one of the other topics I posted on service abstraction. Regardless of the underlying database implementation, the context, purpose and result of the service remains the same. If we applied principles like standardized service contract and service abstraction, the names of the message and the vocabulary used in the messages themselves we would have already abstracted from ANY implementation aspect, including abstraction from the database technology. If we would expose that this service was implemented on a specific database technology we would cause a number of issues<br />
- we can let a consumer 'assume' it is always this technology - basically not giving us the freedom to evolve the service onto another RDBMS product<br />
- we can create a security risk where malicious consumers can target the service is such a way to abuse any weaknesses in the underlying database to get access to data unintentionally, or worse, change the data in ways we don't like etc.<br />
<br />
<b>Conclusion: </b>do not couple the name of a service or service capability to the underlying implementation or RDBMS used.<br />
<div>
<br /></div>
<br />
<h4 style="text-align: left;">
Different versions of a service capability</h4>
Now this one definitely does allow for different service (capability) naming. Just a thing or two that you can pick up from the <a href="http://www.servicetechbooks.com/wsc" target="_blank">Web Services Contracts Design and Versioning</a> book by Thomas Erl et al: Make sure that<br />
- a service is versioned<br />
- a service capability is versioned<br />
- compatible changes of a service do not break the contract<br />
- incompatible changes must break the contract - to facilitate this an incompatible version change of a service is accompanied by a service name change and/or a namespace change (to force consumers to change their implementation as well)<br />
<br />
So initial versions of the OrderService may be called OrderV1. Minor changes would not be reflected in the name; major changes would be reflected in the name. So only an incompatible change can result in OrderV2 service.<br />
<br />
I realize that perhaps this is a bit of cutting corners but it would probably best be covered in another post (working on that post early 2013) as one paragraph would not do the topic any justice.<br />
<br />
<b>Conclusion: </b><i>do not couple</i> the name of a service or service capability to <i>compatible </i>changes to a service.<br />
<br />
<b>Conclusion: </b><i>do couple</i> the name of a service or service capability to <i>incompatible </i>changes to a service.<br />
<div>
<br /></div>
<br />
<h3>
How can service naming improve discoverability?</h3>
<br />
Having the same name for a service capability allows us to better discover a capability. If I would try and find the <i>search </i>capability for Order I would find only one I hope:<br />
- When looking a the details of that capability I would find that (coincidentally) the service was implemented as a web service, is executed in a specific context (order) had one purpose (search for specific orders), had one type of result (list of order IDs), had a specific version (ie. 2.1), supports REST and SOAP; supports specific transports (HTTP 1.1 and JMS 1.0), and what the input and output documents are (more is available perhaps).<br />
- I would (depending on access authorization) not be able to see whether it was implemented on the MS/Oracle/IBM or Tibco platform, I would not be able to see what the versions of these platforms used are, and I would not know what the underlying database technology was.<br />
<br />
If I would follow the other approach an have a different name for every scenario of a capability, this would also mean that I would have to document equally many service capability profiles etc. Finding a specific capability would also be more complex as I would have to know more about the implementation of a service up-front; Ie. if I would not know up-front which different versions of which attribute (platform, transport) etc. exist, I would not know how to find the capability. To me at least this does not make any sense.<br />
<br />
I hope that this post contributes to a healthy understanding of the concerns of service naming and service capability naming. Be aware that this is my view of the topic, and I do realize that probably for each argument why you should or should not change a service (capability) name, a dozen arguments exist to do the opposite. Also I recognize that exceptions may exist which justify a different name where I am arguing for not changing it, I would however treat them as exceptions, not as standard behavior!<br />
<br />
- Roger<br />
<br /></div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-40100397328125143942012-10-11T19:12:00.001+02:002012-10-11T19:13:07.489+02:00Facade or Wrapper or Mediation?<div dir="ltr" style="text-align: left;" trbidi="on">
What is the different between service facade, wrapper service and mediation?<br />
<br />
So here's the problem- there's no standard definition on each of these and since different groups of people mixed up the definitions of these and then some vendor sauce was poured over it, things start getting blurry.<br />
<br />
Let's go back to the basics:<br />
<ul style="text-align: left;">
<li><b>facade </b>- a facade is a component that makes a component appear as something else; </li>
<li><b>wrapper </b>- a wrapper (or better: wrapper service) is a service that wraps a service or system and makes it appear as something else;</li>
<li><b>mediation </b>- a mediation is a component that makes a component appear as something else.</li>
</ul>
<div>
<b>Facade (or Facade Component)</b></div>
<div>
<br /></div>
<div>
A facade component <b><i>is a component </i></b><b><i>inside a service</i></b> that can be used to mitigate for evolving several aspects of a service without the need to change other parts of a service. For example the facade component (or class) can be used to shield:<br />
<ul style="text-align: left;">
<li>contract from evolving service logic -or-</li>
<li>service logic from evolving back end systems -or-</li>
<li>offer multiple contracts for the same logic -or-</li>
<li>offer a standardized contract for a non-standardized component -etc.</li>
</ul>
<div>
The facade component is the most commonly applied design pattern in the world of service-orientation because this is what allows a service-oriented solution to be flexible and cheaper to manage (on the long term). It is a solution that helps manage the cascading effects of changes to the implementation of a service or a back end. Knowing when to position (even an empty one) facade component up-front is key to the successful application of this design pattern.</div>
</div>
<div>
<br /></div>
<div>
<b>Wrapper Service</b></div>
<div>
<br />
A wrapper service <b><i>is a service</i></b> wrapping another service or system. The service architecture (the infrastructure inside a service) can actually <i>contain </i>(a) facade component(s) to make its magic work. Many services are -if you looked at them conceptually- wrapper services. Ie. an <i>entity service </i>exposing a standardized contract can contain a core service logic component to access a database to access but it would typically also contain a facade component to make that database access logic appear as something more usable from standardized-service-contract point of view. Also application-specific public service which are there to accommodate for service consumers that cannot adhere to our standardized service contract are considered wrapper services. Ideally this kind of a service would wrap the standardized service and make it appear in a way that the domain specific service consumer can understand.</div>
<div>
<br /></div>
<div>
<b>Mediation (or Mediation Component) </b></div>
<div>
<br /></div>
<div>
If we look closely at the short explanation of mediation above, we can see that it is the same as for Facade. This was done intentionally to convey an important statement: Mediation is a specific application of a facade; Vendors need to come up with a new "hot topic" now and again - this is the latest greatest commercial name for something that conceptually existed for a long time but is now introduced as the new miracle glue to make vendor products look more attractive. If push comes to shove, mediation should conceptually not be viewed as anything else than a facade component. If we look closely they even exist inside services on most vendor platforms. As a side note: some vendor platforms allow us to place mediation between services, they are then agents placed in the message flow but the purpose of these is the same as a facade component: to make a service appear in a different way. Usually a form of mapping is involved in one way or another.<br />
<br />
- Roger</div>
<div>
<br /></div>
<div>
<br /></div>
</div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-79621930787775248742012-09-22T17:20:00.000+02:002012-10-11T08:05:27.110+02:00Speaking at the service technology symposium<div dir="ltr" style="text-align: left;" trbidi="on">
September 24th, Marc Schmeetz (Vodafone) and myself will be presenting at the service technology symposium in London, UK.<br />
<br />
The topic of our presentation will be on how we improved business and technology alignment in a multi-project programme that lasted for several years.<br />
<br />
This cross-expertise programme involved many business units, suppliers, developers, business analysts, architects and stakeholders and was particularly challenging.<br />
<br />
For more details please see the agenda and presentation profile at the service technology symposium.<br />
<br />
<a href="http://www.servicetechsymposium.com/">Click here for the symposium web site.</a><br />
<br />
<a href="http://www.servicetechsymposium.com/agenda2012.php#conways_law_and_serviceorientation">Click here for the presentation abstract.</a><br />
<br />
- Roger<br />
<br />
<br /></div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-80435834582317407792012-09-21T17:18:00.000+02:002012-10-11T08:20:55.869+02:00SOA, Separation of concerns and agnosticism (5/5)<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
<b>Separation of
concerns and abstraction<o:p></o:p></b></div>
<div class="MsoNormal">
<b><br /></b></div>
<div class="MsoNormal">
Any service that we build should have a certain level of
abstraction. Abstraction comes in many kinds but they are all intended to provide
separation of concerns.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
As an example. if a service accesses a database and the
database has an VARCHAR2() field for a numeric value called DBLADR2FLD, then it
should not matter to the service consumer what the underlying datatype and
column name of the database field is. In essence the service abstracts from the
implementation to prevent this. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Additionally, a VARCHAR2() datatype is a specific vendor
technology datatype. The service should also abstract from the specific
database vendor technology.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Why we do this can be answered pretty simple and
straight-forward: the underlying data model and the database vendor technology
can change over time or be replaced by a completely different system or
technology, and this should not matter to the consumer of the service. This is
the most important reason why we have abstraction. By doing contract-first
approach, we can already make sure that up-front no implementation-specific or
technology-specific dependency can trickle into the contract and as a
consequence into the service consumer logic (see [3])</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Another form of abstraction is the quality of service
abstraction: not all quality of service information does need to be known to
the consumer of a service. Important QoS attributes are the availability and
the reliability of a service, how much load it can handle and what the average
and peak duration of execution is. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Not important however is the fact that the service had 4
failures in the past hour, as this does not say anything about how it will
behave in the future and also it might even make the service look unattractive.
In a sense we need to be shielding these kind of runtime concerns from
potential service consumers. This can be done by creating SLAs that cover the
quality of service in a constructive way with meaningful performance
indicators.<br />
<br />
Many more types of abstraction can be applied - if I can find some more time I will update this article.<br />
<br />
- Roger</div>
</div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-59878983450888949652012-09-20T17:16:00.000+02:002012-09-20T17:16:00.267+02:00SOA, Separation of concerns and agnosticism (4/5)<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
<b>Separation of
concerns and interoperability<o:p></o:p></b></div>
<div class="MsoNormal">
<b><br /></b></div>
<div class="MsoNormal">
Because the contract must be interoperable we need to define
contracts in a technology that is interoperable and preferably vendor-neutral
by nature.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
We also need to make sure that both the message protocol as
well as the transport protocol are standardized as much as possible. Ie. in
case we use a message protocol that cannot be supported on a specific platform
or a transport which is not supported by all required platforms, this poses us
with a significant interoperability challenge. Sometimes both message and
transport are coupled (ie. REST), sometimes decoupled (ie. SOAP where the
message protocol remains SOAP but the transport protocol can change from ie.
HTTP to JMS). </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
For this interoperability challenge to be resolved we can
choose a technology that allows for cross-platform interoperability, like SOAP,
REST or plain XML over HTTP. As you can see the standards used in this
paragraph are all industry standards. Industry standards are standards that
agreed on and have large industry support. As an example, at the time of
writing, SOAP 1.1 has more industry support than SOAP 2.0, so although SOAP 2.0
has some improvements over SOAP 1.1, personally still I would prefer the older
standard.<br />
<br />
Choosing industry standards for the technical contract, the chances of interoperability increase, as multiple different types of platforms would most likely be compatible, despite the platforms being disparate systems.</div>
<div class="MsoNormal">
<br />
As a side note, if technology like SOAP is used, the contract can easily be
designed first because WSDL (yes another industry standard) can be used to describe
the contract in a standardized way (from technology point of view). This would help creating a (separately governed) contract that can be used by both the service designer as well as the service consumer designer to allow for concurrent design and delivery of both service as well as its consumer. </div>
</div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-34266729572429877092012-09-18T17:13:00.000+02:002012-09-19T20:58:40.322+02:00SOA, Separation of concerns and agnosticism (3/5)<div dir="ltr" style="text-align: left;" trbidi="on">
<b>Separation of
concerns and decoupling</b><br />
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
To facilitate standardized contracts, they must be decoupled
as much as possible. Decoupling can be achieved by designing the contract
first, regardless of technology, back end, consumer etcetera.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
A number of different coupling types can be identified.
Generally speaking we distinguish positive and negative coupling types.
Positive coupling types are encouraged whereas negative coupling types should
be avoided. Negative coupling is anything on which the contract can form
dependencies. In other words, contract-to-* coupling is considered negative
coupling and *-to-contract coupling is considered positive coupling as this
reduces the amount of dependencies the contract can form.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
A way of achieving contracts independent of consumers and
implementation is by designing the contract first. If the contract-first
approach is not followed the risk exists that a number of different kinds of
negative coupling find their way into the contract. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Now that we have identified positive and negative coupling
types, the following can be considered positive coupling: </div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
</div>
<ul style="text-align: left;">
<li><span style="text-indent: -0.25in;">Consumer-to-contract</span></li>
<li><span style="text-indent: -0.25in;">Logic-to-contract</span></li>
</ul>
The directly negative coupling types are:<br />
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
</div>
<ul style="text-align: left;">
<li><span style="text-indent: -0.25in;">Contract -to-consumer (contract depends on one
or more consumers of the service)</span></li>
<li><span style="text-indent: -0.25in;">Contract-to-logic (contract depends on the
implemented logic’s interface</span></li>
<li><span style="text-indent: -0.25in;">Contract-to-functional (contract only supports
specific functional context ie. parent process)</span></li>
</ul>
Indirectly another set of negative coupling types can exist,
ie:<br />
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
</div>
<ul style="text-align: left;">
<li><span style="text-indent: -0.25in;">Logic-to-implementation(logic depends on how the
logic is implemented)</span></li>
<li><span style="text-indent: -0.25in;">Logic-to-technology (logic depends on the
technology on which it is implemented)</span></li>
</ul>
Because the contract can depend on the logic, the contract
can indirectly depend on implementation or technology. Examples of negative
coupling are situations where contracts are generated from implemented
components or classes, or components generated to expose a database
implementation.<br />
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Regardless of the coupling type, any negative coupling type
from contract-to-logic will inadvertedly also expose an indirect level of
coupling to the consumer of the service. Ie. the consumer might need to
populate parts of a message to our service which represents ie. a tablename or
fieldname of the underlying back end or database implementation. This will
result in unnecessary changes to cascade though our services into the consumers
and should be avoided in general. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Again, a fairly simple way of avoiding these kinds of
problems is by following the contract-first approach. Another advantage of
contract-first approach is that once the contract is defined (and hopefully
also standardized as described in section 2), is that delivery streams of both
service provider as well as service consumer can make their design and
implementations in parallel, as the interface of the service is predefined with
a clear purpose, context and meaning. This would facilitate a quicker delivery
model than ie. a straight-forward sequential approach where service
implementation had to be finished before the contract can be shared. This would
benefit any project manager, scrum manager etc. as there is no sequential
dependency before the consumer of a service can start designing and developing.
This provides flexibility to the project delivery lifecycle.</div>
</div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-49378287377221356982012-09-17T17:10:00.000+02:002012-09-17T23:59:48.727+02:00SOA, Separation of concerns and agnosticism (2/5)<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
<b>Separation of concerns
and contracts<o:p></o:p></b></div>
<div class="MsoNormal">
<b><br /></b></div>
<div class="MsoNormal">
A significant prerequisite for separation of concerns is the
fact that contracts are standardized in multiple ways. Aspects that can be
standardized on a contract are the data model (service data representation
standardization), and the naming and semantics of the services, operations and
data elements (functional expression standardization).</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Standardizing the contract forces us to separate the concern
of contract design from everything around the contract, this is also called
decoupling (see [3]).</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
A way to standardize and independently govern the contract
is simply by approaching a service using the top-down approach. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This is easier
said than done, but a few pointers are:</div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
</div>
<ul style="text-align: left;">
<li><span style="text-indent: -0.25in;">Expression of functionality from the viewpoint
of business and business processes</span></li>
<li><span style="text-indent: -0.25in;">Naming entities from the viewpoint of the
business functional area they support</span></li>
<li><span style="text-indent: -0.25in;">Applying normalization and logic centralization
to services</span></li>
<li><span style="text-indent: -0.25in;">Creating the contract-first, only then think
about the implementation</span></li>
</ul>
<!--[if !supportLists]--><br />
<span style="font-size: 11pt; line-height: 115%;"><span style="font-family: inherit;">Once t<span style="font-family: inherit;">he contracts are designed first, there is
a natural decoupling of contract and logic, as the contract ideally should not
expose any implementation details. The separation of concerns is reached
specifically by the contract-first approach as this </span></span></span><span style="font-size: 11pt; line-height: 115%;"><span style="font-family: inherit;">does
not allow implementation-specific details to trickle down into the contract.</span></span></div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-5329839941574925372012-09-15T17:08:00.000+02:002012-09-15T17:08:00.600+02:00SOA, Separation of concerns and agnosticism (1/5)<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
<b>Middleware and Separation of Concerns</b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Middleware can exist in many ways but most common approach
is either the application service or the ESB approach. Regardless of what
platform or technology the middleware is hosted on, the main purpose of the middleware layer is the same:
separation of concerns.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
As an example the following picture shows that the
middleware decouples the consumer from the back end systems by providing
services that act on behalf of the back end. This way the consumer does not
need to be concerned with the back end, and the back end does not need to be
concerned with who the consumer is or how it works.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Decoupling should be explained a bit further. Two systems
are coupled if there is a dependency between the two. What we try to achieve
with decoupling is that we try to minimize the amount of dependencies between
them.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Separation of concerns can be observed in middleware in many
ways but starting with offering services on the middleware platform allows us
to wrap back end systems. This then allows us to offer a standardized way of
accessing underlying back end systems. Standardizing the access to logic can
improve interoperability. To provide increased opportunity of interoperability,
we need to understand that we have to standardize contracts. If two systems are
interoperable it means that they can easily exchange information, or in other
words, cooperate. If we put in lots of effort we might be able to provide a
system that has something called intrinsic interoperability.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Intrinsic interoperability is achieved if we have
standardized a system in such a way (and if we have built logic in such a way
that the interoperability can be supported) that if two systems exchange
messages, the messages can be easily understood, without the need for (complex)
transformations or translations.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
For intrinsic interoperability to be achieved, a number of
prerequisites must be met, and even then matters are not easy and require
significant amount of attention in the governance area.</div>
</div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-22938141370289090442012-09-14T17:07:00.000+02:002012-09-14T17:07:35.894+02:00SOA, Separation of concerns and agnosticism (0/5)<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal">
<b>Separation of
concerns and agnosticism<o:p></o:p></b></div>
<div class="MsoNormal">
<b><br /></b></div>
<div class="MsoNormal">
Separation of concerns and agnosticism are two
closely-related terms. Where separation of concerns is a term commonly used in
object-oriented and component-based technologies, it is a way to clearly
separate functional concerns by defining containers (services, classes,
components) to identify a functional boundary of the contained operations.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Agnosticism (from the Greek word <i>agnostos</i>) is a term traditionally used in religion-related
discussions but also in the world of service-orientation to explain that the
service is not aware of, or is not concerned with, the parent functional
context. <i>Gnostos</i> means “aware of the
existence of”, the “<i>a</i>-“ is a negation
making the whole term’s meaning “<i>not</i>
aware of the existence”.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Both terms convey a similar concept where we keep concerns
of a particular piece of code local to that piece of code only, and not have it
scattered across the software infrastructure. The term agnostic however intends
to apply to a wider scope than only code or logic, for instance on the contract
or on the service as a whole, as well as the entire service inventory
structure.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This five-part series touches on several aspects of how
separation of concerns can be achieved in a service-oriented solution.</div>
</div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-62232097516555081692012-08-07T20:09:00.002+02:002012-09-14T17:19:51.267+02:00Just finished reviewing Thomas Erl's upcoming book SOA with REST<div dir="ltr" style="text-align: left;" trbidi="on">
Hi all,<br />
<br />
I just finished reviewing the upcoming book SOA with REST, written by Thomas Erl et al.<br />
<br />
For more information about this no-nonsense book, see the <a href="http://servicetechbooks.com/rest">SOA with REST</a> infopages.<br />
<br />
- Roger</div>
Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-78109938404296399442012-08-06T22:33:00.002+02:002012-08-06T22:35:14.591+02:00Now official trainer for the Service technology Symposium<div dir="ltr" style="text-align: left;" trbidi="on">
Now I am also official trainer for the Service Technology Symposium, for training partner Rhea Solutions Ltd.<br />
<br />
For the training program see the <a href="http://www.servicetechsymposium.com/workshops2012.php">training web site</a>.<br />
<br />
I am conducting the pre-symposium <a href="http://www.servicetechsymposium.com/workshops2012.php#soaarchitect">Certified SOA Architect Workshop</a>. Also see the Symposium's <a href="http://www.servicetechsymposium.com/dl/Workshop_Guide_2012.pdf">Workshops Guide</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.servicetechsymposium.com/dl/resources/Banner_900x201.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="88" src="http://www.servicetechsymposium.com/dl/resources/Banner_900x201.jpg" width="400" /></a></div>
<br /></div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-73607159673744369782012-08-06T22:10:00.004+02:002012-08-06T22:11:20.611+02:00Now official speaker at the Service Technology Symposium<div dir="ltr" style="text-align: left;" trbidi="on">
Hi all, now I am<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="http://www.servicetechsymposium.com/dl/resources/badge_04_100x100.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.servicetechsymposium.com/dl/resources/badge_04_100x100.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
For more details see: the official <a href="http://www.servicetechsymposium.com/">Service Technology Symposium web site</a>, and the <a href="http://www.servicetechsymposium.com/speaker_bios.php?id=roger_stoffers">presentation abstract and speaker profile</a> for "<b><i>Conway's Law and Service Orientation</i></b>".</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
- Roger</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br /></div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-8559462511738712582012-02-01T08:23:00.003+01:002012-02-01T08:23:34.860+01:00Published the Centralized Event Consumer candidate pattern<div dir="ltr" style="text-align: left;" trbidi="on">
Hi all,<br />
<br />
I just published the <a href="http://soapatterns.org/centralized_event_consumer.php">Centralized Event Consumer</a> SOA Pattern. The pattern increases autonomy of underlying resources in large event architectures, thereby increasing the event consumer autonomy.<br />
<br />
You can view the pattern by following the link.<br />
<br />
I would like to ask everyone to review & give feedback on the soapatterns.org website. Also in case you have used the pattern yourself successfully, please testify this at soapatterns.org using the feedback form, so the pattern candidate might be qualified as a real pattern.<br />
<br />
- Roger</div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-62031610362992335102012-01-26T06:45:00.002+01:002012-01-26T06:45:46.512+01:00Published an article in Service Technology Magazine<div dir="ltr" style="text-align: left;" trbidi="on">
Hi all,<br />
<br />
I just published an article in <a href="http://www.servicetechmag.com/">Service Technology Magazine</a> - the January 2012 edition.<br />
<br />
For those of you who read my blog it might be familiar text as I took one of my posts as basis for the published article. For those of you who want to check it out you can <a href="http://www.servicetechmag.com/I58/0112-2">see it here</a>.<br />
<br />
- Roger</div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-91123009160860948732011-04-20T22:50:00.004+02:002011-05-17T21:29:51.575+02:00Coupling processes loose - a mess if not done right<div dir="ltr" style="text-align: left;" trbidi="on">Another great example how processes can sometimes be coupled in such a way that you can create a mess for the people in the process (tight coupling):<br />
<br />
As posted in my previous post, I am using a chip-card for the Dutch Public Transport. This card acts as a travel pass and allows loading products onto it which act as tickets for public transport. More information can be found <a href="http://www.ov-chipkaart.nl/?taal=en">here</a>.<br />
<br />
One of the ways for travelling with the card is by loading credit products onto the card which act as a virtual wallet. You can do this manually, or you can load a product onto it which behaves in such a way that if your credit on the card drops below a certain threshold, it automatically does a debit transaction on your bank account and recharges the travel card. For this to work you need to purchase the product online and link it to the bank account of your choice.<br />
<br />
I had almost activated the product on my card until I noticed the following phrase in the description of the product: "Always make sure sufficient money is in your bank account. If we cannot obtain the money from your account the card will be blocked. Unblocking the card can be done at a service desk."<br />
<br />
Now here's the problem: two processes exist which are mixed incorrectly here:<br />
- travel authorization<br />
- debit transactions<br />
<br />
Specifically the scenario when travelling with insufficient credit on the card and a low bank account balance causes issues: why would anyone want to block the entire travel card if I had insufficient balance?<br />
<br />
There are a number of reasons why this is wrong and additionally there is one specific reason why this is fundamentally wrong:<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">- Travelling is registered/credit is consumed by checking in and out of the travel registration system by keeping the card close to a registration point (the card uses near-field-communication to communicate with the travel management system</div>- Insufficient credit for this travel does not mean that there is insufficient credit for all travel. It should be sufficient to deny check-in for this travel only.<br />
- Insufficient bank balance still allows me to recharge the card from another bank account - so why block the entire card?<br />
<br />
Fundamentally wrong:<br />
- Many train stations and most bus stations do not have a service desk. To get to one I would need to travel!? Blocking the card does effectively restrict me from getting to a service desk.<br />
<br />
What is documented here is an unnecessarily tight coupling between two distinctly different processes with distinctly different purposes. A better solution would have been to check at every check-in time anew whether or not I had to recharge the card. If the bank account balance was insufficient I would be denied that particular check-in.<br />
<br />
Needless to say I did not activate that auto-recharge-card-credit-product on my card. You never know what happens and I do not intend to get stuck in the middle of nowhere just because an architect made a mistake (imho) by tightly coupling two disparate processes and by doing so shuts me down completely (travel-wise).<br />
<br />
Wonder how long this situation will exist now that the government and the transportation companies are trying to get rid of the paper travel tickets...<br />
<br />
- Roger</div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-10967826684946167212011-04-01T22:17:00.004+02:002011-04-12T20:20:59.721+02:00Transportation service compared to SOA service (over)specialization<div dir="ltr" style="text-align: left;" trbidi="on">Sometimes service over-specialization can truly hinder reuse in a sense that multiple implementations of similar logic are necessary to achieve the same functional goal for another purpose (agnostic).<br />
<div><br />
</div><div>I live in the Netherlands where recently an electronic public transportation ticket system was introduced to manage travel tickets electronically. A chip card with NFC is used to 'carry' digital tickets while travelling. You could see the travel pass as a digital purse in which you can keep single/return trips, monthly and yearly subscriptions as well as some money to use while travelling.</div><div><br />
</div><div>Now I'm new to this system and finally I decided to try the 'ticket recharged' way of travelling: the public transportation chip card instead of a paper ticket.</div><div><br />
</div><div>In order to be able to travel, I need to meet a number of preconditions:</div><div>1. I need a (personalized) travel card - this is the actual chip card with NFC communications</div><div>2. I need to put money on it</div><div>3. I need to activate "travel" on it with the appropriate transportation company.</div><div><br />
</div><div>Ad 1): I already had the card a little while, so I did not need to worry about it: precondition 1 is met.</div><div>Ad 2): For charging the card with money intended for travelling, a two-step approach must be followed:</div><div>a. Purchase travel credit - this would perform a direct debit on my bank account</div><div>b. Load the credit product onto the card</div><div><br />
</div><div>Ad 3): Similar two-step approach:</div><div>a. Order the "travel by virtual travel money" product with the dutch railway company</div><div>b. Load the product onto the card that allows using the credit on the card if available</div><div><br />
</div><div>Step 2a can be done via the public transportation chip card web site</div><div>Step 3a can be done via the dutch railways web site</div><div><br />
</div><div>So now I needed to find an NFC charging point so I found one of the terminals for public transportation at the train station.</div><div><br />
</div><div>Now here's the problem:</div><div>The machine to load products onto the card would only allow me to find the pending product for step 3a. This means I can load the product to spend the virtual money with, but I cannot find the product that represents the virtual money I had ordered to spend in the first place.........?</div><div><br />
</div><div>So the "Load product" service on the terminal was only able to load travel products but no credit products. What was wrong with building a load "product"???</div><div><br />
</div><div>I ended up finding another machine outside the railway station to load the money product onto the chip card...</div><div><br />
</div><div>So I had to load products in two physically separate (and distant!) places...</div><div><br />
</div><div>Typical example of a non-agnostic service... :(</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div><div><br />
</div></div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-55374176509630244362011-03-16T22:26:00.000+01:002011-03-16T22:26:20.045+01:00Published the Context Normalization Standardization pattern candidate<div dir="ltr" style="text-align: left;" trbidi="on">Hi all,<br />
<br />
I just posted the pattern candidate for (Process) <a href="http://soapatterns.org/context_normalization_standardization.php">context normalization standardization</a>.<br />
<br />
If you have done this before and agree this is a good approach to solve cross-company process and technology alignment, please testify on the <a href="http://soapatterns.org/">soapatterns.org</a> web site using the candidate pattern feedback form.<br />
<br />
Thanks,<br />
<br />
Roger</div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-74465144922727688822011-02-18T20:14:00.002+01:002012-04-26T16:55:45.211+02:00Agnostic/non-agnostic revisited<div dir="ltr" style="text-align: left;" trbidi="on">
I got the feedback that the previous article I wrote on what agnostic/non-agnostic is was too complex. So I am revisiting the subject to make sure that I explain a lot simpler than in the post I described last year.<br />
<br />
To explain as easily as possible what agnostic/non-agnostic is:<br />
<ul style="text-align: left;">
<li>agnostic services are not aware of the context in which they are being called, nor are they aware of how the service is implemented, which platform, technology etc.</li>
<li>non-agnostic services can have one or more forms of coupling or context (ie. process functional context).</li>
</ul>
<div>
Result of these two statements is that agnostic services have more reuse potential than non-agnostic services.</div>
<div>
<br /></div>
<div>
An example of the difference can be identified by discussing a "PrintInvoice" service capability.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHlLxw__lXi7PmdY6jEdQa0nHl2125hoepcBIwVeporDqgOgLQ0sRNhofDjIparc6kWjwTqV4vG5wCFZXts2pXkECSN-QHKJMdRqYh-10AK3NcxYRT4QhGfpt2sM1t1NZyt1qBlcUtC2Y/s1600/printinvoicenonagnostic.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHlLxw__lXi7PmdY6jEdQa0nHl2125hoepcBIwVeporDqgOgLQ0sRNhofDjIparc6kWjwTqV4vG5wCFZXts2pXkECSN-QHKJMdRqYh-10AK3NcxYRT4QhGfpt2sM1t1NZyt1qBlcUtC2Y/s1600/printinvoicenonagnostic.jpg" /></a></div>
<div>
<br /></div>
<div>
This is a service capability which can be described as the logic exposed to print an invoice. When trying to classify the service it is pretty obvious that this is a non-agnostic service, as it has capabilities to print invoices and nothing else.</div>
<div>
<br /></div>
<div>
When applying the principles of service design, we should give a service a defined logical (functional) boundary, which defines the context in which the service operates.</div>
<div>
<br /></div>
<div>
When redesigning the implementation of this service, we could split the service into two services:</div>
<div>
<ul style="text-align: left;">
<li>Print</li>
<li>Invoice</li>
</ul>
</div>
<br />
These are two agnostic services: print service capabilities are bothered with the capability to print "stuff" and Invoice service capabilities deal with invoice related "stuff".<br />
<br />
Having made this separation, I just lost my capability to print invoices. To resolve this problem I can create a third service which combines the two services in one service capability which can deal with the mechanics of printing invoices, which results in the following service-inventory:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4znZuig4OcKjKPCC__i20AIMZRnKIFyDpbskcvpg7ETGKlJrai_27sn-KDib9Rewzgtyn6TeOAFq7N-IwlzBSTvbn3RQD2T6ukkBRzpGp77KBh59xfFr6mYGNNUXkH1qZu7nVhJaxoQE/s1600/printinvoiceagnostic.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4znZuig4OcKjKPCC__i20AIMZRnKIFyDpbskcvpg7ETGKlJrai_27sn-KDib9Rewzgtyn6TeOAFq7N-IwlzBSTvbn3RQD2T6ukkBRzpGp77KBh59xfFr6mYGNNUXkH1qZu7nVhJaxoQE/s1600/printinvoiceagnostic.jpg" /></a></div>
<br />
<br />
As you can see the agnostic services are being composed by the non-agnostic PrintInvoice service. This allows for the invoice and the print service to be used for other purposes, of which I have depicted a few potential examples below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsuWQ7gIYZNIouqj3kqE7VA3VZeAf3feM_h9_IYqa3OUlSyuIeQ8DluDKgbvPVGZCoDRmRnj4iUBu69_pLqw0qVsKtz9AHF7wb6j62N0QqjQuAAuWOPVOapLUQPeN5sgE9tlRNkVJI9I4/s1600/printinvoicereuse.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="144" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsuWQ7gIYZNIouqj3kqE7VA3VZeAf3feM_h9_IYqa3OUlSyuIeQ8DluDKgbvPVGZCoDRmRnj4iUBu69_pLqw0qVsKtz9AHF7wb6j62N0QqjQuAAuWOPVOapLUQPeN5sgE9tlRNkVJI9I4/s320/printinvoicereuse.jpg" width="320" /></a></div>
<br />
As we can see, it's the agnostic services which are being reused, not the non-agnostic services.<br />
<br />
If this separation of concerns would not have been applied, instead of ie. reusing the print functionality, for the printletter functionality, the printing part would have been redeveloped and tailored for the printing of letters. This would have created some unnecessary/redundant/duplicate logic.<br />
<br />
The current PrintService would take any range of different document types that it would support. This would greatly enhance the reusability of the agnostic print service.<br />
<br /></div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-57996668742680228302011-02-02T22:15:00.003+01:002011-02-02T22:15:00.202+01:00Published Rule Layers candidate pattern<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">Hi all,</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"><br />
</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"><br />
</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">I just published the</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"> </span><a href="http://soapatterns.org/rule_layers.php">Rule Layers</a> candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out <a href="http://soapatterns.org/rule_layers.php">here</a> at <a href="http://soapatterns.org/" style="color: #445566;">soapatterns.org</a>.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">- Roger</span></div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-69802564249605236832011-01-17T21:05:00.000+01:002011-01-17T21:05:09.189+01:00Published Rules Normalization candidate pattern<span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">Hi all,</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"><br />
</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"><br />
</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">I just published the</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"> </span><a href="http://soapatterns.org/rules_normalization.php">Rules Normalization</a> candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out <a href="http://soapatterns.org/rules_normalization.php">here </a>at <a href="http://soapatterns.org/" style="color: #445566;">soapatterns.org</a>.<br />
<br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">- Roger</span>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-39520751101823958072011-01-09T22:06:00.002+01:002011-01-18T16:05:48.695+01:00Make sure it's not too CLOUDy...This post addresses some of the concerns that companies might have when dealing with cloud services in general, specifically when dealing with sensitive data in a hosted environment. Where cloud computing in intended to increase the quality of service, the quality of "privacy" is not a generally recognized factor when services are hosted. The environment naturally protects its applications because that's what the hosting environments provide.<br />
<br />
With cloud computing, the deal changes with respect to traditional hosted services in ie. a colocated hosting environment for which you know where it is hosted. When services are hosted in a cloud, ie. the service's storage resource is hosted in redundant locations, you can not be sure with a (public) cloud where a service or its resources are hosted. In fact, some of the more innovative cloud service providers have dynamically hosted resources in 'cooler' locations on the planet to save cost by requiring less power for cooling. This means that the services are hosted across multiple continents and in many countries, which naturally leads to the conclusion: what happens with my customer data, what happens with my client data?<br />
<br />
Businesses or governments storing data in a cloud may inherently be exposing the data into countries which have different privacy policies or legislation than required for their purpose. For example, if data of a European company is stored outside the European Union, which means that data of customers may not be protected by the privacy laws of Europe.<br />
<br />
In the example, a cloud consumer should stick to cloud providers for which he knows the privacy policy, and for which the hosting environments are only located in Europe. Alternatively a cloud consumer should build a private cloud or use a community cloud which has controlled access.<br />
<br />
Similar approaches apply for different reasons and for different countries, but the essence stays the same: make sure it's not too <i>cloud</i>y...Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-89782215086543827732010-12-17T21:12:00.009+01:002010-12-17T21:12:00.434+01:00Core service logic and auxiliary service logicHere's a nice scenario I have encountered recently:<br />
<br />
Customer management wants <i>every</i> activity performed by a customer and every customer contact logged in the customer data store.<br />
<br />
For this purpose, every relevant service and process in the service inventory is fitted with auxiliary logic to create customer logs in the CRM system.<br />
<br />
Historically, this has worked for several years, but recently the system administrators started complaining about the sheer amount of data in the system and how it is becoming very hard to keep the system displaying these logs to the CM agent without running expensive (long-running) queries.<br />
<br />
To cut a long story short, they want to reduce the amount of data logged for a customer by creating a new policy which only logs significant activities on a customer record.<br />
<br />
For this to work, the initial request was to remove the logging logic from certain service capabilities.<br />
<br />
In the service inventory, a whole bunch of services has, besides the relevant core service logic, some hard coded auxiliary CRM logging logic which will use a utility service to push the logged data to the CRM system.<br />
<br />
As it is impacting many different services which are used in different contexts, removing the auxiliary logic as requested may not be the best way to go about this. Not only does this cost a lot of effort and regression testing, but also does it not solve the issue that the same service should log to the CRM system in one context, but not in another.<br />
<br />
An alternative, perhaps more flexible way of changing the system's logging logic, is to change the utility service or apply a policy to this service which acts as a filter, deciding for all services whether or not to execute the actual CRM system update.<br />
<br />
This means that the logging logic can still stay in the services as auxiliary logic, and the decision whether or not to perform the actual update will happen in the CRM system can be managed (declaratively), external to the core service logic of the services needing the logging, and external to the actual logging service itself.<br />
<br />
This can work only if the context of the service call is also recorded with the logging message.<br />
<br />
An alternative to this approach can be that all services log messages to the CRM system per default, but publish the message into a queue or topic and selectively process messages based on business rules in a business rules engine or similar.Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-74627733116158868152010-12-13T23:11:00.016+01:002010-12-13T23:11:00.394+01:00SOA Pattern Publishing - why?!Hi all,<br />
<br />
Recently I have been posting a lot of candidate patterns on <a href="http://soapatterns.org/">soapatterns.org</a>, the pattern-related site of <a href="http://soasystems.com/">soasystems.com</a>.<br />
<br />
I was a matter of time before someone might ask "what are you doing and why are you doing it?". Well, it happened. Anyway, the reason why I wrote this post is because people ask why use soa patterns, why document soa patterns and there's only one simple reason for me doing this.<br />
<br />
SOA patterns are <u>proven solutions</u> for <u>common problems</u>. Some of the candidate patterns I have documented may seem like open doors or a shot at an empty goal - but that's a good thing actually. What it means is that people recognize a certain solution for a problem, to actually be a good or at least a viable solution. And if people recognize the structure of the solution, does that not mean that they have just recognized a pattern in what they are seeing?<br />
<br />
SOA patterns are not rocket science. SOA patterns are not smart or unique solutions. They are merely a common way of fixing a problem that we've encountered more than just once.<br />
<br />
Does that mean it should not be documented? I don't think so. By documenting it, I hope to save other people's time and effort; because if someone recognized a documented soa pattern as something that can be applied to their problem, with or without modifications, that particular goal is reached.<br />
<br />
Why am I publishing candidate patterns and not patterns? Well, it's in the definition of the soa pattern. For it to be a pattern it must be proven - as in - used in the field by more than one person. A site like <a href="http://soapatterns.org/">soapatterns.org</a> manages exactly that. This is also why I'm asking with every candidate pattern published by myself, to get others to testify that they have used the same pattern or a similar approach for real too. Because only if a group of people would testify they use it, it can be considered a pattern instead of a candidate pattern.<br />
<br />
Keep watching this blog for a couple of more patterns to come. Presently finalizing patterns on rules normalization and rule layers and a couple of more service inventory related patterns. And if you've done something similar to what's described in one of my pattern candidates - or any others in the list - be sure to let the people at soapatterns.org know that you did. This way you, the community, can contribute to the field.<br />
<br />
Regards,<br />
<br />
-RogerRoger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-16352491523280296452010-12-06T20:49:00.000+01:002010-12-06T20:49:31.653+01:00Published Reference Data Distribution candidate pattern<span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">Hi all,</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"><br />
</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"><br />
</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">I just published the</span><span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;"> </span><a href="http://soapatterns.org/reference_data_distribution.php">Reference Data Distribution</a> candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out <a href="http://soapatterns.org/reference_data_distribution.php">here</a> at <a href="http://soapatterns.org/">soapatterns.org</a>.<br />
<br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Trebuchet MS', Verdana, Arial, sans-serif; font-size: 13px; line-height: 18px;">- Roger</span>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0tag:blogger.com,1999:blog-7640798319190572752.post-48385113567476361222010-11-29T21:59:00.000+01:002010-11-29T21:59:28.980+01:00Throttling is not trivialRuntime governance tooling vendors, when they present their tools for ie. throttling, the way this is presented to potential customers is that they explain how installing these is easy and how implementing the actual behavior of the actual service agents is configuration only and this can simply be done by system administrators.<br />
<br />
The pitfall is that customers exist who infer from these statements that they can purchase the licenses for any required service agents, give the CD to an administrator, and ultimately let the system administrator configure the throttling agents into the service inventory. All problems solved.<br />
<br />
Let’s start by defining what throttling actually is from several points of view and then we can go from there to illustrate that these conclusions can be way off and can be very costly to resolve.<br />
<br />
In the eyes of customers, throttling is a way to manage the amount of traffic to a service or a back end system. Expectation is often that they manage the amount of throughput by restricting the access to a service to not exceed a certain metric, ie. a specific number of calls per second or per minute, depending on load.<br />
<br />
What does a statement like this mean, to the messages that arrive at the throttling agent and are marked to be beyond the predefined threshold?<br />
<br />
For a customer this could mean that the message has to wait until the measured load does not exceed the threshold anymore.<br />
To a throttling agent this usually means that the service call cannot be executed, because executing this would violate the expected threshold even more.<br />
<br />
<b>Throttling examples</b><br />
<br />
What should happen to a service call exceeding the threshold? This actually depends on the purpose of a service and the context in which this service call is executed. A few examples are:<br />
<ol><li>A read call for customer data intended for display in a client application</li>
<li>A read operation in the context of an update service composition</li>
<li>An update of an address based upon a client application request</li>
</ol><br />
Let’s highlight some characteristics for each of these:<br />
<br />
Ad 1)<br />
It seems OK to respond “too busy” to the service consumer. The consumer can retry in less busy times if it’s really important. To the throttling agent it means it’s ok to discard the message and respond “too busy”.<br />
<br />
Ad 2)<br />
This scenario is distinctly different from the first one. Discarding the read message to be executed in the context of an update, will most likely trigger a retry mechanism. The retry mechanism will make the same message come back potentially even quicker than a retry attempt coordinated by a service consumer. This will significantly increase the resource load on the message infrastructure as well as on the throttling mechanism. A way to overcome this issue is to have message properties which help identify in which context the message is being executed. And on the same throttled service, but in the different context, you can decide to allow this service call although messages in the ‘regular read’ scenario would be refused. For this you can even use two different throttling statistics.<br />
<br />
This does however expose an issue related to throttling in service composition context. For elaborating this see the part of the article titled to “Where to throttle in the SOA”.<br />
<br />
Ad 3)<br />
A little less easy to deal with. Discarding the message does most likely not meet the business requirements. If the front end application (service consumer) is a web application which exposes a page to submit address changes, it might even cost customers ifthe data was typed and the system would say “too busy”. But then what? It seems that storing the message and trying later in less busy times should be fine.<br />
<br />
One has to ask himself now whether the order in which messages are processed is significant in the context of the core service logic. This determines whether it’s fine to park requests which exceed the threshold for later execution. Even if the requests are parked for later use, this is just moving the problem to another place in the system or to another point in time. If the amount of throttled (parked) messages is big, when processing the parked messages you may face another throttling challenge. If we’re just moving the problem it does not seem like a viable solution.<br />
<br />
If the order of execution is to be guaranteed, the solution mentioned cannot be executed as no new messages can be executed until the one exceeding the throttling policy can be successfully processed. This is another solution which does not seem viable to solve the throttling issue.<br />
<br />
What other options do we have? If we look at this scenario, the throttling should do no more than manage that messages do not get lost while the availability of the service provider is not guaranteed (the throttling policy exceeded situation is the same as having an availability issue of the service provider). This can be solved by utilizing a queue to mitigate for the times of reduced availability of the service provider. This should be sufficiently supporting that (eventually) the address update is being executed.<br />
<br />
A way of throttling in this situation is to have messages read from a queue (the messages posted by a service consumer) at a maximum predefined rate to prevent the throttling policy from being violated. This can only be done if the consumer does not require a synchronous response to its update request message. This is a perfectly fine solution where no messages get lost, the order of execution is maintained only if messages are read from the queue one at a time which then seriously impacts the scalability of the throttled service.<br />
<br />
The processing order of messages is relevant if out of order execution causes data integrity issues or service failures. Some examples are: two subsequent address changes on the same customer result in the incorrect address details in the customer database if executed out of order. Or similarly, if the core service logic of a service must create subsequent service calls, and the second one cannot be completed successfully without the first one being executed successfully, this will create similar data inconsistency issues.<br />
<br />
A way to make the system more scalable is when messages can be skipped if a more recent one was received; this applies in certain situations only. When taking the two subsequent address changes as an example: only the most recent message for the address change is relevant to the system. This can be achieved by assigning a time based or sequence based message property or header element to a message upon receipt by the service consumer. Perhaps the service consume can already assign this to the request. If an expression can be used to identify whether a processed message can be dropped because a more recent one has been processed before. (A similar system can be used to detect replay attacks). For this to work, a form of data store must be available in the system to keep track of these requests.<br />
<br />
<b>Where to throttle in the SOA?</b><br />
<br />
Where should throttling happen anyway? There is no single right answer to this topic. Let’s consider the following layered service inventory:<br />
<br />
a - Public services controlling the access to services inside the service inventory, acting as an endpoint for all external access to the service inventory<br />
b - Orchestration services (orchestrated task services) controlling all centralized and long-running processes<br />
c - Business services (ie. task services, utility services) which are the sole access point to any underlying layer<br />
d - Data Services (ie. entity services, utility services) controlling all back end access.<br />
<br />
What happens if we throttle on services in each of these layers?<br />
<br />
Ad a)<br />
This can control the amount of traffic allowed into the service inventory but what does that achieve? It would only achieve throttling on that level in the infrastructure. It would be good for controlling specific service consumer policies and indirectly keep the load on the underlying system manageable but in the end, many public services can access the same business services or back end services in complex compositions resulting in a significantly greater amount of requests to the back end which can be a multitude of the amount of client requests. Furthermore, not all business service would need to be exposed on public level, meaning that load can exist on the lower layers inside the service inventory that the throttling mechanism would not be measuring.<br />
<br />
Ad b)<br />
A system can hardly be throttled on this level, as process starters are often inside the orchestration engine and cannot be exposed to service agents. This means that if a process must be controlled, it’s probably best to throttle externally to the process, ie. in the layers ‘above’ or ‘below’ the orchestration layer. Or by controlling the flow of messages to and from the process in general.<br />
<br />
Ad c)<br />
Business services might seem to be the best place to control throttling because they see all the traffic coming into the system has to pass by a business services. They see the traffic from the top layers and the traffic from the layers below. But multiple business services may be composed together in complex compositions, resulting in a throttling nightmare when the need to throttle arises on these kinds of services. For example, if I had an order service which is used in a composition which should also invoice the customer and schedule an electronic payment, on which of these elements (functional business service areas) do I throttle? On one of the composed services? On the service composition controller? On all? Even here a single answer is not possible because it all depends on the purpose of the throttling and potentially this differs per throttled service.<br />
<br />
Ad d)<br />
This can control the back end load probably best, but as the data access services usually do not know the context in which they are being called, applying the throttling on this level has its restrictions. Referring back to 2) if the read of underlying data is relevant for an update operation on the same service composition, then what kind of an effect does refusing the read operation have on the service composition, and what is the consequence of that to the bus infrastructure? This is not easy to answer as it is probably different for many services.<br />
<br />
In the end I think it all comes down to <i>why </i>the throttling happens from business or technology point of view. Sometimes the throttling happens to protect the legacy and back end systems, which should allow for throttling on data service level. Sometime the throttling happens to protect the middleware from excessive load, which can probably best be manages at business service level. Sometimes it’s one specific consumer which can threaten the entire system’s availability and then a throttling policy for selected relevant service capabilities exposed to that particular consumer may be used to protect other consumers from the load caused in the middleware by the throttled one.<br />
<br />
Each method has it’s pros and cons. When looking at the overall picture, it may be perfectly fine to throttle on two or three levels. Although a combined throttling policy may not be the most easy to comprehend and it may not be using the system resources to the best extent, it still remains a popular method as it guards a number of key parameters of the system. This results in a solution which is still manageable without the need for capacity enhancements.<br />
<br />
Of course throttling policies can be used in other ways, for example to give priority to certain messages, or messages from certain consumers or customer requests on the system, and many other ways exist, but this post is just an example and I can never convey all the issues and opportunities of throttling in one single post.<br />
<br />
<b>Dealing with throttled services in a reference architecture.</b><br />
<br />
I hope that this post conveys that throttling is not trivial. In fact it’s crucial to have an up-front analysis done for your throttling architecture before any policy is applied. This can be formalized by documenting specific approaches for specific situations in a reference architecture document.<br />
<br />
A well-respected colleague of mine once said: the throttled message can be discarded and the service consumer can be thrown a technical exception. Although this may be fine for many messages and throttling implementations, please be aware that more options exist and can be addressed by having a throttling (reference) architecture.<br />
<br />
A throttled service may throw a technical exception. Usually technical exceptions are treated by consumers as a permanent failure for a service call. If the call was a read operation, probably it may not happen again, but if it’s a write operation, the consumer may have retry mechanisms in place which might immediately result in another call with the same message, This however is the easiest and most straight-forward implementation and can be introduced without really big implementation issues in the system. Most initial implementations may be using this method. Some caution with this statement: if the consumer treats this as an invalid message call to another system, some elaborate log analysis sessions may come from this, since people cannot tell the difference between a back end availability issue and a throttled message response. To make this difference, you may not be able to avoid customization of the services.<br />
<br />
A throttled service may throw a technical or functional status (“not now”) but in the end this means that the service consumers must be able to understand this message. What it means is that at present the message cannot be completed. Probably it does not make sense to retry the message at this point in time but a retry at a later time may work perfectly well. This means that a delayed retry may succeed after all, whereas an immediate retry would not.<br />
<br />
Once a reference architecture exists, it should be easier for system administrators to think about and implement new policies, and fine-tune throttled entities. But be aware that, depending on how elaborate the throttling architecture is, the complexity of throttling may dramatically increase. Even if current throttling parameters are understood perfectly well, a dependency analysis must be conducted to be able to fully assess and understand the implementation of a new throttling policy.<br />
<br />
A similar risk may apply for making changes to an existing throttling policy. As soon as you tune the throttling policy to switch close to a point near “typical load”, or the typical load increases to a value near the configured throttling policy, dramatic changes in system performance and behavior can be expected.<br />
<br />
My advice would be to have and changes or new policies investigated by a team which consists of administrators (system current knowledge), architects (system dependencies and consequences) and capacity planners (system future load). <br />
<div><br />
</div><div>Throttling is not trivial; it's as simple as that!</div>Roger Stoffershttp://www.blogger.com/profile/18257182295766299860noreply@blogger.com0