Channel 9 has just published some videos on BizTalk Services, a.k.a the Internet Service Bus (ISB), providing services (S+S/SaaS) for your mashups. This is an ARCast.TV episode with Ron Jacobs: part I and part II.
Absolutely worth watching, BizTalk Services is a central part of the "Oslo" initiative.
Wednesday, October 31, 2007
Tools and platform for providing SOA and mashups
This week at the Microsoft SOA and BPM conference, two announcements were made that support the predictions of my last post (SOA: Top Two Tech Topics for 2008):
Read more about "Oslo" in the Directions on Microsoft article provided on Christian Weyer's blog.
- Managed Services Engine v6.2 (service virtualization)
- The "Oslo" SOA and Software+Services platform for composite applications
Read more about "Oslo" in the Directions on Microsoft article provided on Christian Weyer's blog.
Friday, October 26, 2007
SOA: Top Two Tech Topics for 2008
As Gartner has published their 'Top 10 Strategic Technology Areas for 2008', of which several are related to SOA; this is my two cents about two more specific topics that are important for you as an architect and developer of service-oriented systems:
Read the relevant articles to learn more about these indeed very technical topics, you really cannot manage a complex set of hundreds and thousands of services without such SOA operations and lifecycle governance technologies. Microsoft is on the ball with the BizTalk ESB Guidance and the partnership with AmberPoint (in use at Vital Forsikring in Norway) and SOA Software.
Also check out the Connected Services Framework being used at telecos around the world (watch video). You can play with aggregated services and managed network mashups at the Connected Services Sandbox.
Read the relevant articles to learn more about these indeed very technical topics, you really cannot manage a complex set of hundreds and thousands of services without such SOA operations and lifecycle governance technologies. Microsoft is on the ball with the BizTalk ESB Guidance and the partnership with AmberPoint (in use at Vital Forsikring in Norway) and SOA Software.
Also check out the Connected Services Framework being used at telecos around the world (watch video). You can play with aggregated services and managed network mashups at the Connected Services Sandbox.
Sunday, October 21, 2007
BizTalk Services SDK, RelayBinding: Firewall Issue
I recommend that you download and try the samples of the BizTalk Services SDK (identity & access control, connectivity, web-style stuff) to get a deeper understanding of what the "internet service bus" concept provides to service-oriented solutions - both for the SaaS approach and for the Software+Service approach.
An error that you might run into when trying any of the connectivity samples is the "No DNS entries exist for host connect.biztalk.net" exception when calling host.Open() from e.g. the EchoSample server. You'll get a really lost feeling when googling for this error gives no hits:
System.ServiceModel.EndpointNotFoundException was unhandled
Message="No DNS entries exist for host connect.biztalk.net."
Source="System.ServiceBus"
StackTrace: at System.ServiceBus.RelayedOnewayClient.Connect()
The cause of this problem is that the RelayBinding uses an outbound TCP connection to connect to sb://connect.biztalk.net/ to set up your hosted endpoint; and if you're behind a firewall, this will fail unless permitted by the firewall. Refer to the ReadMe file of the SDK for more details.
An error that you might run into when trying any of the connectivity samples is the "No DNS entries exist for host connect.biztalk.net" exception when calling host.Open() from e.g. the EchoSample server. You'll get a really lost feeling when googling for this error gives no hits:
System.ServiceModel.EndpointNotFoundException was unhandled
Message="No DNS entries exist for host connect.biztalk.net."
Source="System.ServiceBus"
StackTrace: at System.ServiceBus.RelayedOnewayClient.Connect()
The cause of this problem is that the RelayBinding uses an outbound TCP connection to connect to sb://connect.biztalk.net/ to set up your hosted endpoint; and if you're behind a firewall, this will fail unless permitted by the firewall. Refer to the ReadMe file of the SDK for more details.
Sunday, October 07, 2007
Information Model Mediation: Esperanto vs Babel Fish
In my quite popular post SOA: Canonical "Data" Model (picked up by Steve Jones, David Linthicum, Jean-Jacques Dubray and others), I used two analogies for the semantic mediation needed when composing different services into business processes: Esperanto and the Babel fish. This post is about how the two approaches differ in their use of the business process information model (BPIM). But first a short recap of the two terms:
Esperanto is a common world language; when you learn it, you can speak with any other person in the world that also known Esperanto. Everyone does of course still have their native language. See how similar this is to services that interact using a common information model (CIM) to express themselves, while every system still use their own domain model inside.
A Babel fish is a small fish that you put in your ear, which is capable of simultaneously translating any known language in the universe to yours, while adapting semantics between galaxies. See how similar this is to services that interact using a common logical data model (LDM) while every system still uses their own domain model to express themselves.
Both these approaches to semantic mediation in service-oriented solutions do use a business process information model (BPIM). They differ only in how they implement the transformation between formats: inside the services or outside the services.
The CIM approach to mediation is to use the BPIM directly in the service contracts and apply the transformation within the provided services [Hohpe/Woolf: Messaging Mapper pattern (477)]. This is a simple and viable approach; the services are self-contained, but require a bit more to implement and test due to the extra mediation requirements. The services will also need to be changed and tested when the BPIM changes. Dan North suggests this approach in his 'A Low-Tech Approach to Understanding SOA' article. This is still the most common approach, especially for those without an ESB.
There is one minor challenge with the CIM approach: chances are that the Esperanto of an alien galaxy will differ from your Esperanto. Thus, when outsourcing an activity service such as 'credit check', you need to adapt to the service provider's business concepts. So even if you use a CIM for all your enterprise services, you will still need to implement some sort of mediation to do the context mapping between the two federated business domains.
The huge advantage of the CIM approach is that it doesn't require any ESB-style intermediary. The services speak "CIM" natively and thus no transformation to/from the common data model is needed. Note that the service implementation must still map between the CIM format and its internal data formats.
The LDM approach involves using an orchestration mechanism to compose business processes from the set of domain specific services. The services just provide their functions independent of who the requesters (consumers) are and how they try to interact with the services. Think of your SOA solution as having Event Driven Architecture (EDA) to free yourself from "invoking operations" and think of business events and messages instead. It is the task of the Babel fish to mediate and transform the messages sent between consumers and providers [Hohpe/Woolf: Message Translator pattern (87)]. The intermediary can be just the service composition mechanism, but an Service Bus is a more robust and flexible mediation and transformation mechanism.
The LDM approach makes the services themselves simpler and easier to implement and test as they now have just a single responsibility. The services need not change when the BPIM changes, that complexity has been shifted to the intermediary. Implementing semantic mediation outside the services is proposed by Jack van Hoof, David Chappell (Pope of ESB), Bobby Woolf and many others.
Esperanto is a common world language; when you learn it, you can speak with any other person in the world that also known Esperanto. Everyone does of course still have their native language. See how similar this is to services that interact using a common information model (CIM) to express themselves, while every system still use their own domain model inside.
A Babel fish is a small fish that you put in your ear, which is capable of simultaneously translating any known language in the universe to yours, while adapting semantics between galaxies. See how similar this is to services that interact using a common logical data model (LDM) while every system still uses their own domain model to express themselves.
Both these approaches to semantic mediation in service-oriented solutions do use a business process information model (BPIM). They differ only in how they implement the transformation between formats: inside the services or outside the services.
The CIM approach to mediation is to use the BPIM directly in the service contracts and apply the transformation within the provided services [Hohpe/Woolf: Messaging Mapper pattern (477)]. This is a simple and viable approach; the services are self-contained, but require a bit more to implement and test due to the extra mediation requirements. The services will also need to be changed and tested when the BPIM changes. Dan North suggests this approach in his 'A Low-Tech Approach to Understanding SOA' article. This is still the most common approach, especially for those without an ESB.
There is one minor challenge with the CIM approach: chances are that the Esperanto of an alien galaxy will differ from your Esperanto. Thus, when outsourcing an activity service such as 'credit check', you need to adapt to the service provider's business concepts. So even if you use a CIM for all your enterprise services, you will still need to implement some sort of mediation to do the context mapping between the two federated business domains.
The huge advantage of the CIM approach is that it doesn't require any ESB-style intermediary. The services speak "CIM" natively and thus no transformation to/from the common data model is needed. Note that the service implementation must still map between the CIM format and its internal data formats.
The LDM approach involves using an orchestration mechanism to compose business processes from the set of domain specific services. The services just provide their functions independent of who the requesters (consumers) are and how they try to interact with the services. Think of your SOA solution as having Event Driven Architecture (EDA) to free yourself from "invoking operations" and think of business events and messages instead. It is the task of the Babel fish to mediate and transform the messages sent between consumers and providers [Hohpe/Woolf: Message Translator pattern (87)]. The intermediary can be just the service composition mechanism, but an Service Bus is a more robust and flexible mediation and transformation mechanism.
The LDM approach makes the services themselves simpler and easier to implement and test as they now have just a single responsibility. The services need not change when the BPIM changes, that complexity has been shifted to the intermediary. Implementing semantic mediation outside the services is proposed by Jack van Hoof, David Chappell (Pope of ESB), Bobby Woolf and many others.
Thursday, October 04, 2007
Enterprise-Level Business Concepts
Dan North has expanded on Arjen Poutsma's SOA 'holiday request form' analogy in his post 'A Low-Tech Approach to Understanding SOA'. Applying the paper form analogy to design the interactions and messages of your business processes is an approach that I really recommend.
What got my attention was the recommendation at the end of the post in the 'Avoid a universal domain model' section: Do not introduce an “enterprise information architecture” / “universal data dictionary” trying to force everyone to use the same domain model. Instead, introduce business concepts. This is effectively the higher-level, ubiquitous language that ties together all of the finer-grained domain models behind each service. The services use the enterprise-level business concepts when interacting, which decouples the service consumer from the service provider and allows them to evolve independently.
This is spot on with my advice for making a business process business process information model (BPIM) and avoid enforcing a "enterprise data model" or "canonical schemas" across your services. Not only does BPIM allow for loosely-coupled, evolvable services; it also allows for the services to be semantic covenants which is important for service composition.
What got my attention was the recommendation at the end of the post in the 'Avoid a universal domain model' section: Do not introduce an “enterprise information architecture” / “universal data dictionary” trying to force everyone to use the same domain model. Instead, introduce business concepts. This is effectively the higher-level, ubiquitous language that ties together all of the finer-grained domain models behind each service. The services use the enterprise-level business concepts when interacting, which decouples the service consumer from the service provider and allows them to evolve independently.
This is spot on with my advice for making a business process business process information model (BPIM) and avoid enforcing a "enterprise data model" or "canonical schemas" across your services. Not only does BPIM allow for loosely-coupled, evolvable services; it also allows for the services to be semantic covenants which is important for service composition.
Subscribe to:
Posts (Atom)