 |
|
RUP for SOA and SOMA - confused? you may not be...
Well, as usual I have left things a long time to put together a new posting, but a number of questions from inside and outside IBM have spurred this discussion. As some background the topic of this post, the relationship between the RUP for SOA content and the SOMA method, can be seen as a specialized discussion based upon Bill Higgins Rational Method Composer posting where he discusses the reconciliation between the IBM Rational Unified Process and the IBM Global Services Method. Where Bill focuses on the discussion of these two methods as broad frameworks I would like to focus on particular areas of these two methods that seem to be causing some confusion.
Firstly, the Service-Oriented Modeling and Architecture (or SOMA) offering is an extension of the IGS GSMethod and is available to IBM customers through service engagements (see the IGS SOA services here). This means that the techniques are described in a certain manner, and based on existing techniques included in the existing GSMethod base. From "Analysis and Design Techniques for Service-Oriented Development and Integration" SOMA is described as:
SOMA is an IBM offering that defines the three service modeling steps identification, specification, and realization. These steps consist of several sub-steps prescribing several artifacts to be delivered and recommending appropriate techniques ...
SOMA identification can start both from business models via domain decomposition, which includes functional area analysis and process decomposition, and from existing systems. An additional goal-service modeling technique ties business goals, for example expressed as Key Performance Indicators (KPIs) to the identified service abstractions, facilitating runtime monitoring of business goals (a key business performance and service management issue).
It is the combination of techniques specific to SOMA, the GSMethod base and the IGS professionals that provide the value to our customers - a value that can be enhanced by using Component Business Modeling (CBM) to identify areas where a migration to SOA will provide most benefit, and then traditional development practices for service implementation.
Conversely the RUP for SOA is a commercial product, the RUP itself as a framework and base has been adopted by many organizations over the years. The RUP for SOA plug-in was only a set of additional artifact and activity descriptions that extend the existing RUP content. This approach has meant that the RUP for SOA is entirely consistent with existing techniques and is able to leverage them as it does not attempt to be a stand-alone method. However, this does not imply that there is no relationship between SOMA and RUP for SOA as you might think (and the existence of two separate methods from IBM has confused many people) as SOMA describes the use of many techniques that really are generic and described in both GSMethod and RUP, such as Use Case Analysis.
In fact, as there is almost no dependency from SOMA to proprietary GSMethod techniques, it would be possible to describe the techniques and artifacts in SOMA as extensions to the combination of RUP with the SOA extension. The initial work is underway, both teams have made some changes in the methods and content to align terms and concepts where possible; also the content describing SOMA is being captured in Rational Method Composer (RMC) so the delivery of the two methods uses common tooling. The next, and most significant step is another round of consolidation where we can finally describe techniques in SOMA in terms only of the RUP and RUP for SOA techniques, and while SOMA will remain an IGS engagement method, the alignment between our services method and commercial offering will be complete. I hope to be able to report more news on this work over the next few months - I exect there will be many meetings and phone calls in the meantime.
Finally, as an aside Joe Marasco (previously of Rational) forwarded the following link which takes a wonderful and irrevelant look at the subject of software development processes - enjoy www.waterfall2006.com.
Technorati: SOA, RUP
Mar 01 2006, 01:22:00 PM EST
Permalink
|
|
IBM and Model-Driven Architecture
It seems that while IBM has published quite a lot of material on Model-Driven Architecture (MDA) in both formal and informal settings I have been asked a number of times by customers where they can get some material to read and review the IBM position on MDA. So, recently Alan Brown sent out a note with a list of resources available on MDA from IBM authors. At first I was going to simply squirrel the email away so I could forward it to people when next they asked me for some material, but I decided that it might be interesting to those reading the developerWorks blogs. So, here is a good list of articles which cover a number of MDA topics and present a complete view of MDA from an IBM/Rational perspective. There are other papers from IBM which include aspects of MDA or have a very model-driven theme.
Hope that's plenty of bed-time reading for everyone!
Technorati: MDA
Nov 29 2005, 02:39:00 PM EST
Permalink
|
|
New article series on developerWorks
Just as a quick note, one of the items that has kept me busy the last few weeks has been the preparation and writing of a series of articles for developerWorks. The first in this series on modeling of Web Services is now published. The second should hopefully follow relatively soon.
Modeling Web services, Part 1 - XML Schema
One of the items I highlight in the second article on modeling of web service interfaces is that the Rational Software Architect team has made two sample transformations available via the developerWorks RAS repository - the UML to XSD and UML to WSDL transformations. While these are useful in themselves, for those that want to write their own transformation these are written by the dev team and supplied in source form. Have fun.
Technorati: SOA
Nov 29 2005, 02:38:00 PM EST
Permalink
|
|
Service Identification - Top-Down or Bottom-Up?
Again, this seems to be an interesting topic - how should you identify the services you develop for a given solution? Top-down would suggest that you analyze your business processes, identifying activities in support of your process that become candidate operations on service specifications (see a previous post on the view that services and processes are the primary concerns of Enterprise SOA). A Bottom-up approach would suggest that you analyze existing applications and assets to identify those that will are candidates to be "service-ified". The reason I want to step into this debate is that there seem to be more and more people writing on the subject of development processes for SOA development who take very specific stands on which of these are more valuable.
So, which is right for you?
Well as usual the answer is that there is no right answer; this is a sliding scale and how much of each technique you use will depend very much on the solution you are developing and the development processes you follow. I met with a customer a week or so ago who is very much struggling with this decision, and specifically feels that the current literature indicates that Within the RUP rather than using these top-down and bottom-up terms which instantly give the feeling of contradiction we simply identify a set of techniques that may be used for service identification. The following picture is taken from the RUP update for SOA and demonstrates these techniques quite simply. they have to pick one over the other.
In terms of the use-case and business process techniques, these are more top-down approaches whereas the remaining techniques are more focused on the analysis of existing assets. So, let's take a look at the advantages and disadvantages of the top-down vs. bottom-up approaches in general.
- Top-down - Has the advantage that the services identified throughout the layers of the solution are aligned with the business processes which provided the scope for the solution. It is also attractive from a project management perspective in that the business process under consideration provides a natural project scope for the development effort. However, the major drawback to this approach (and the reason the customer I mentioned earlier got unstuck) is that it becomes harder to ensure that you develop services for reuse (some thoughts on SOA and Reuse) as developers are looking to develop services that support this process rather than ones that will contribute to an enterprise-wide service portfolio.
- Bottom-up - A bottom-up approach has the potential to develop a set service that can support a number of processes, addressing the concern above, as the developers are looking across a broad set of artifacts. The issues here are that where data is the focus of the artifact analysis the tendency is to generate CRUD services (which is bad) or to develop access operations that do not match well the requirements of processes and therefore require business services to make multiple calls into data-management services.
The best advise right now seems to be that you should lead with a top-down approach, that development teams and projects should be managed in such a way, but, in parallel you should have an SOA architecture team that can review service specifications, propose existing services for reuse and validate new services to ensure they fit into the enterprise service portfolio. This really frees project teams from having to understand all the existing portfolio, and allows the architecture team to also capture reuse guidelines and to act as intermediaries between different project teams. This does not imply that there is no bottom-up identification, but that it happens within the scope of a project which is top-down.
P.S. Beware any development process that dictates such a rigid set of techniques and an equally rigid step-by-step approach - for there you will find a process that has either only been used on a single project or never been used at all.
Technorati: SOA, RUP
Oct 06 2005, 10:47:00 AM EDT
Permalink
|
|
CRUD vs. Business Operations/Events
I recently sat through an interesting presentation, given by one of our consultants, on the application of SOA at customers. In general it was a good solid presentation, and after all as a practitioner solving real problems the speaker had instant credibility in my eyes. One moment did make me chuckle at the time, but more importantly stirred me to some deeper thought over the last few days. The speaker was discussing the issue of defining operations for services and the oft-stated desire to ensure that developers do not build CRUD services. I'm sure most SOA-aware architects are familiar with the principle that while we are trying to create more granular services we need to analyze the data concerns and needs for operations, certainly update transactions need to be carefully considered.
Specifically let us consider the usual "Customer" example, we do not want to see an operations updateCustomer(AllOfCustomer) for a number of reasons. Firstly the update to the database has to work out what has changed and if the underlying representation is across a set of tables (which it has to be) then the update is a complex transaction. Secondly there are business rules that may be applied to certain updates, for example when we update a customer address within an insurance company we may find that the new address will invalidate a customers policy or at least change their premiums or coverage. So, we provide a set of update transactions, such as updateAddress() or updateDependencies().
Back to the original speaker, his comment was that these are still CRUD operations, that they should be changed to be Business Operations such as changeCustomerAddress() or customerHasMoved(). While the first of these simply changes the word update for change, which doesn't seem to change the semantic in any way. However, interestingly the second alternative is substantially different, its language is not expressing an action to take against the customer but denoting a change in the state of the real-world entity represented by the software Customer. As such we are dealing with something much more like a business event, and while this was not the intent of the original speaker I think this is a very important observation, it allows for a much more flexible approach to a business service definition, a service that manages an entity in this way can express a set of direct operations that change the underlying data but also a set of business events that it responds to. These business events are a great way to also look at integration scenarios; existing Enterprise Application Integration often focuses on Event-Driven Architectures and the distribution of events across and between services using mechanisms such as pub/sub messaging or the Enterprise Service Bus.
I want to come back to the broader discussion of the relationship between SOA as an architectural style and message-oriented architectures and programming models in a later posting, for now I'd love to get peoples feelings on this idea of recasting some of these update transactions as events.
Technorati: SOA
Oct 04 2005, 04:16:00 PM EDT
Permalink
|
|
Enterprise SOA
Well, it has been a while since I managed to sit and write here, with a long family vacation and some very interesting trips to IBM labs and customers in Europe pretty much filling up the month of August. One recurring theme however is one I've touched on here before and that is the fact that as we think more and more about "service-ifying" the business and developing an IT infrastructre based on SOA principles and patterns one issue has to be addressed and that is how we develop a truly enterprise-wide perspective on this new IT world. Already we are seeing terms such as service fabric describing this enterprise wide network of services, service repository to describe the additional metadata seemingly required for integration and service library which seems to be a kind of service repository for developers... So, you can be forgiven for thinking the IT world has lost it's head, until you realize that there is an underlying need that is bing poorly represented by this plethora of new dictionary terms. Though before we leave this I will admit that we used the term service portfolio within the RUP update for SOA. What we are really trying to convey is that the Enterprise we envision is one whose technical capabilities are expressed entirely as services[1] and that we believe there will be a greater level of reuse across this IT landscape due to the nature of services (see here for a discussion) and so understanding how these services collaborate in support of business processes will be key.
The problem is that with SOA in general is that we are trying to tackle two really hard problems in one go; specifically one hard technical problem and one hard organizational problem (I'll leave it to the reader to decide which is the harder). The first is the need for integration technologies and approaches for the leverage of IT assets that actually works (seemingly a minor requirement or even an afterthought in many organizations). The second is the need not to bridge the Business/IT gap (see here for a discussion) but to eliminate the concept - to say there is an enterprise which achieves it's aims through business knowledge and IT capabilities which are inseparable. Some customers are moving toward such a model where projects are not conceived in the business world and then thrown over the wall to IT for implementation but where teams consist of business and IT folks from inception through to delivery and in some cases into the monitoring and optimization as well. Fundamentally the key concept, or rather the concept that should be key, in the business domain is the business process as it is really the delivery vehicle for the value that a business provide. And yet right now in IT we have so many key concepts you'd need to sit for a week with a dictionary to get to grips with them - the concept of a service has the value of providing a single abstraction that due to it's granularity can be used to describe the actions performed as steps within a business process, this there is a common vocabulary now in terms of business actions and services. It is in this approach that we see the real need for an enterprise-wide view of the services that IT provides, the capabilities of the IT that support the business processes, we need to be able to identify services that exist that may be reused in a given solution, we need to be able to see the current and planned interaction between services as we expand the portfolio and finally we need the ability to use this information during design, implementation and integration phases.
I read a good article entitled Service Orientation in Enterprise Computing from Mike Burner at Microsoft while I was traveling and Mike touches on some of these topics (and uses the service portfolio term). Specifically Mike introduces the separation of service orientation as the technologists view of the patterns and practices for service development, and the Service Oriented Enterprise or SOE which is the set of processes used to manage the IT service portfolio.
Each well-designed service and service-oriented solution becomes part of the organization's technology portfolio, components in the service-oriented enterprise. The hallmarks of a successful SOE are rigorous service factoring, a thorough, forward-looking integration strategy, and a common, coherent approach to the management and governance of services and solutions.
This separation is very useful as it allows us to describe the set of processes that govern development of individual services, that govern the development of a solution and that govern the management of the service portfolio as separate lifecycles that share common goals and many common activities. In this regard IBM is set to extend and re-release the current RUP for SOA plug-in with specific guidance on the development of a service portfolio as a broader governance activitiy. This additional guidance, developed in conjunction with our customers, we hope to be able to make available on developerWorks before the end of the year.
This does lead us nicely back to a point made in the first paragraph above, when you start to discuss the term SOA Governance you very soon end up discussing SOA Registries. As we have seen, this is inevitable as the nature of the SOA Governance processes are to manage the service portfolio, one expression of which may be through a service repository. However, there is a second aspect here, which is a vendor and analyst push to convince uss that we all need a global run-time repository of service metadata. In the RUP we certainly recommend that there be a design-time model of the services in your enterprise, if you are using modeling tools to design your solution from services it seems only appropriate to have your portfolio accessible in the same medium. However we do discuss the need for, or at least the desirability of a central repository for service specifications and additional information. So should we not be able to provide concrete guidance on the form this repository should take? Well as it turns out we have a number of standards applicable in this area as well as a number of vendors competing for the limelight. So what about standards in this area? Well it seems we have a choice of standards, both interestingly enough now under the OASIS banner, UDDI and ebXML Registry[2] as well as the possibility of using the Reusable Asset Specification (RAS) as a means to describe the metadata associated with services. As for vendors, there are companies such as such as LogicLibrary looking to recast existing repositories for an SOA purpose as well as new players such as Systinet, Infravio and AmberPoint providing a specific SOA play.
Notes:
- Note, when using the term services I do not imply a) web services, there may not be any HTTP or SOAP in sight, and b) that these are new-fangled things, COBOL on CICS is still a fine way to build IT capabilities.
- While most of the above vendors have chosen to build repositories around UDDI one, notably Sun (Sun registry) has chosen to also implement the ebXML registry.
Technorati: SOA
Sep 06 2005, 11:16:00 AM EDT
Permalink
|
|
Service == Operation, Interface, Implementation ?
Well, this discussion has been going on within IBM for some time now and obviously affects things I've covered here such as the UML Profile for Software Services where we had to model services. Understanding the conceptual model for a service seems critical yet there are some very strong opinions and precedents to take into consideration.
- The Web Services View; in the web services world services are primarily described using WSDL, therefore we can take the WSDL view of a service as being the collection of endpoints accessing an implementation of a portType (in turn having a set of operations or message exchanges). So service tends to get equated with the actual implemented, running "thing".
- The Design View; when we look at designing services we want to focus much more on the abstract definition of a service capabilities - in WSDL terms the portType - than the implementation details of the bindings and endpoints. This is not to say they are not important, specifically whether a service can meet it's quality of service goals can depend greatly on the transports and encodings chosen. So for many the service is the interface defining it's capabilities and this service may have multiple instantiations.
- The Action View; if you take a process decomposition approach to identifying services you often end up with a set of actions that are the leaf tasks in the process, implementing each as a service would imply that a service maps well to an operation (in programming language terms). In fact until recently the RUP for Systems Engineering1 Architecture Framework used a modeling approach that used UML operations as the definition of services.
So what, is it really that important to know whether a service is modeled as an operation or an interface? Well it turns out that it does matter, and it matters quite a bit. For example, those who prefer the decomposition approach whereby they end up with a catalog of "actions" that are invoked by a process consider each action a service "place order", "check availability", "update customer address", and while this is appealing and does seem to match well with the concept of "service" in every day use it has a particular drawback. Let us consider the "place order" service, if I think of the last time I placed an order for goods with a retailer it seems reasonable to consider the placing of the order as a service provided by the retailer - an atomic action. Except that it isn't, granted that in most cases everything goes well and the next I know of my order is the arrival of goods; however modeling this as an operation does not allow me to cater for the case where ordering is a more complex activity. In the e-retailer case this may be that I am told that an item is out of stock, would I like to wait for all my items to be available (therefore reducing shipping costs) or ship the available items now? In a business to business setting this conversation can get even more complex, I can ship you 10 today with the balance next week, or I can ship you all of the quantity of this compatible product, or we can wait for next week.... So it seems that really a service needs the ability to be defined in terms of a potential conversation, the sum of which is the action we identified supporting our business process.
We also mentioned that there is a notion that when we use the term service we mean the implementation artifact. In this case the drawback is simply that binding the service and interface in this way to become a single entity does not readily allow me to reuse service specifications and separate out the specification of the expected behavior from the actual implementation, and possibly multiple implementations of a given specification. It is vital therefore that whatever terms we use, service, interface, specification, contract, that we clearly separate and continue to manage the specification and implementation of a service as distinct elements.
Now there are also potential drawbacks to using an interface-like structure to defining a service - for example where some services really are single operations (for example there will most likely be a set of low-level data access services that are best modeled as independent transactions) then the overhead of a single provider implementing a single interface with a single operation can become cumbersome. Yet this really becomes a tooling issue - one which we IBM have to step up to, to make sure that our modeling and construction tools cater well for both the simple and more complex cases without over optimizing one over the other.
Interestingly the most schizophrenic discussion of the notion of a service can be found in a single source - the UML 2.0 specification. Here are a selection of the entries I found when I did a search through the specification for the word service.
From the glossary:
operation
A feature which declares a service that can be performed by instances of the classifier of which they are instances.
From the definition of Implementation
The set of interfaces implemented by the classifier are its provided interfaces and signify the set of services the classifier offers to its clients.
From the definition of Interface
An interface declares a set of public features and obligations that constitute a coherent service offered by a classifier.
From the definition of Component
A component specifies a formal contract of the services that it provides to its clients and those that it requires from other components or services in the system in terms of its provided and required interfaces.
From the definition of Connector
The interface compatibility between provided and required ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services.
From the definition of Port
A Port may specify the services a classifier provides (offers) to its environment as well as the services that a classifier expects (requires) of its environment.
The isService property of Port
If true indicates that this port is used to provide the published functionality of a classifier; if false, this port is used to implement the classifier but is not part of the essential externally-visible functionality of the classifier and can, therefore, be altered or deleted along with the internal implementation of the classifier and other properties that are considered part of its implementation. The default value for this attribute is true.
The service stereotype in the Intermediate profile
A stateless, functional component (computes a value).
The EJBService stereotype in the J2EE/EJB Component profile
Indicates that the Interface is an EJB Service interface that is exposed as a webservice definition.
So, be warned, whichever stand you take on this you will upset someone, on the other hand it is usually true that if you don't upset someone with an idea then it's probably not a useful idea :-)
Notes
- It seems that there is a rendering issue with this page using Firefox on Windows; it seems to work fine with IE on Windows, Safari on MAC OS X.
Technorati: SOA, UML
Jul 22 2005, 11:24:00 AM EDT
Permalink
|
|
RUP/SOA mentioned in Forrester article
Access to the full article is only by purchasing from Forrester, but the mention of the "much needed guidance for teams building SOAs" was gratefully received. So for those with access to Forrester, take a look at the report Big Changes Coming For Rational Unified Process by Liz Barnett, Carl Zetie and Lindsey Hogan.
Jul 22 2005, 08:48:00 AM EDT
Permalink
|
|
More on modeling services
OK, so I mentioned over on Don's blog that I would write up some more on our SOA modeling as well as design thoughts to go along with the announcements we have made over the UML Profile, RSA plug-in and RUP update (details of these downloads are here). Within the RUP guidance we discuss the idea that one of the ways in which an SOA fundamentally changes the way we look at applications. For more discussion, check out this article I recently completed for The Rational Edge (e-zine on developerWorks). Now, in general it is true that SOA is not, in itself, radically new and technologies such as web services, BPEL and so on are more evolutionary than revolution, but the combination of new design approaches, standards and middleware technology does introduce and underline a particular aspect of note. Applications, as we have previously considered them, do not exist in an SOA based environment - a grand statement but hopefully you'll understand what I mean as you read on.
Traditionally in most development organizations we have treated the "application" as a distinct boundary, not just in terms of code, but in terms of project management, requirements gathering and so on. So, even when component technologies such as COM, CORBA or J2EE are used we still tend to act in the same "monolithic" way that we did with legacy systems development. Frequently when you talk to developers in an IT organization (or even some larger ISVs) and ask them what they do they tell you "work on xyz application", we build organizations/teams around these boundaries, we assign staff and budgets and manage schedules around development or maintenance of applications. Now, we all know there are some shared elements, usually components that wrap up technology issues and of course the dreaded shared database. So why would we say that introduction of SOA changes this in any way? Well, a number of factors in the development of services leads us to services that tend to be at a coarser grain than typical components in J2EE (and I know this is a subjective measure) and so tend to focus on decoupling dependencies with other services. In developing a set of enterprise-wide services in this manner we really develop a fabric of peer services, services that are developed independantly, developed for reuse across the business and developed defensively with contracts that define the behavior provided by the service and expected of the consumer. This fabric of services represents the basic functionality of our IT capability, but how do we bring them back together to provide end-user capabilities? Well processes provide the threads that connect together services in end-to-end flows supporting end-user requirements.
- Services; The set of business and technical functions published for reuse by processes. Services may be relatively short-lived, transactional data access elements, encapsulate business logic or business rules, or provide access to infrastructure software such as messaging, monitoring and so on.
- Processes; The flows supporting end-user requirements, choreographing services, note that a service may actually be implemented as a process, so there is a potentially recursive nature to the relationship between services and processes.
So, we see that really processes and services represent the two primary aspects of SOA; you cannot consider one without considering the other and it is the combination of service and process that really represents an application. So, we have moved from an application as a hard boundary for development to something which is far more dynamic, a particular pattern woven through the fabric of services.
This has some impact on the current organization of many IT departments - organization of development should be around the development of these services, developing them using tools, techniques and standards appropriate to their purpose (when much of the data that will be needed by services still exists in systems such as CICS). Similarly organization of knowledge should be around the processes, with interaction between the business stakeholders and IT architects focused on the precise understanding and modeling of the services that will be automated in support of the business.
Technorati: SOA, MDA
Jul 21 2005, 02:43:00 PM EDT
Permalink
|
|
Presenting Best-Practice and Guidance
As I mentioned in the last posting I have been working on an update for the Rational Unified Process (RUP) providing guidance for SOA development. This has been an interesting journey, and while I have worked with RUP and helped customer use and leverage RUP this has given me a whole new insight into the process and more specifically the guidance emboddied in the RUP. I have also been asked to work over the past few weeks on an internal white paper and a part of this has been to describe the way we manage, package and provide best practices and guidance to our customers, I thought this was an interesting list and as all of this has been public discussed here is the list straight from that paper.
- Process; this is typified by the RUP and provides a set of disciplines, workflows and activities to be performed by all stakeholders in the development of solutions. The RUP today is delivered as a pre-defined set of content and a set of tools to allow customers to add new content, remove content and deliver a tailored process.
- Guidance; usually in the form of documentation that describes guidelines for the development of a certain artifact, or the execution of a process activity. Guidance can delivered as simply descriptive text, or as active content in the form of Eclipse “cheat sheets”. This guidance frequently describes how an artifact or activity may be tailored for a particular environment, for example the differences between design models for embedded device and SOA business application development.
- Examples; small, pre-built examples of artifacts described by the guidance above. Based on the assumption that most people learn more effectively by dissecting a working prototypical solution these samples provide a concrete way to consume and understand the guidance.
- Templates; pre-built starting points, these are not complete solutions but partial solutions with the “user adds here” identified extension points. Templates again are a useful way to get users over the “blank screen” problem of many tools and getting them started, we are all used to templates in tools such as MS Office, we aim to provide richer and richer sets of templates in all of the SDP.
- Patterns; pre-built solutions to a common problem, these are elements of a model or solution and typically have variability points or arguments to the pattern to integrate them into a design or implementation. Patterns can be applied at different levels of models (business, analysis, design) as well to implementation artifacts and can be woven together.
- Recipes; a set of patterns and guidance that provides a higher level of automation in a given domain, so allows the user to describe a higher level requirement and the recipe can instantiate the correct patterns, in conjunction, to move closer to a given solution.
- Solutions; a set of recipes focused around a given solution architecture where the solution has a framework into which components fit, these components can be built (or configured) using recipes which in turn use patterns and guidance in the completion of the framework. Solutions can be built around both technical frameworks or industry frameworks (such as IAA).
Now, as for packaging both the Rational Software Modeler and Rational Software Architect come with a pre-configured instance of the RUP which is not only accessible from the Process Browser but also we provide a view called the Process Advisor which is a context sensitive presentation of topics from the RUP according to the activities you are performing in the tools. For example if you create a use-case diagram you will see the process advisor list all topics to do with the creation of use cases, requirements and also guidelines on good use case design. This guidance from the RUP is also being augmented using the Cheat Sheet capabilities which is now available as part of the Eclipse platform and allows for automated step-by-step instructions on performing a given set of tasks within the tool. Obviously we provide samples and templates as a matter of course, check out the the Samples Gallery and Tutorial Gallery in the product, and expect those extending the products to provide such samples and templates with their extensions (for an example, check out the RSA plug-in for Software Services which includes a profile, template model and sample gallery entries).
Patterns have been a very key part of our modeling products since the original launch of XDE and the pattern authoring and application process have become far more powerful and usable in the RSM and RSA products (we have also included the ability to develop both model-to-model and model-to-text transformations). The work done to-date on patterns is being extended right now to include tool support for recipes and solution templates - for those who attended RSDC you should be able to download the Design and Construction Keynote and the talk by Grant and Alan Service-Oriented Architecture for Mere Mortals: Practical Lessons for Migrating Your Organization to Service-oriented Solutions and Technologies which include discussions on solution templates. Overall it is this focus on Asset-Based Development (ABD), that along with SOA, I see as one of the most important challenges and most interesting opportunities in the tool space in the near term.
Oh, and interestingly all of these elements lend themselves to being packaged, described with metadata, searched and instantiated in RSM/RSA allowing users to significantly customize the products to their environment and needs. In this regard the Reusable Asset Specification (RAS) is a key element of this value proposition in providing a common way to describe and categorize assets either delivered by IBM, 3rd parties or harvested from projects by the users themselves. The delivery, in RSM/RSA, of the RAS browser and other RAS tooling allows for the capture, description and publication of assets from models and code as well as the browsing, downloading and instantiation of assets from RAS repositories.
We live in interesting times ...
Technorati: rup, uml, mda
May 31 2005, 01:07:00 PM EDT
Permalink
|
|
Rational Software Development Conference 2005
Well, it's that time of year again, the Rational Software Development Conference and unfortunately this year I will not be able to attend. I have worked with Sky Matthews on putting together a talk "DC36: Approaches for Design and Construction of Next Generation Services and Service-oriented Solutions" based upon the work we mentioned here (and Don Ferguson so kindly linked to) on modeling Service Oriented Solutions. We have now completed the set of artifacts around modeling services, including RUP guidance:
- UML Profile for Software Services documentation.
- UML Profile for Software Services, Template Model and Samples packaged as an RSA plug-in.
- RUP Update for Service-Oriented Architecture as a RUP plug-in
For those who are unable to attend the conference, like myself, you might like to know that developerWorks has asked a select set of senior IBMers to blog specifically on the conference and you can find these entries here starting this Sunday.
May 20 2005, 04:59:00 PM EDT
Permalink
|
|
UML Profile for Software Services
A couple of things, separate but related. Firstly I want to announce that we have made available a paper describing our UML Profile for Software Services. This profile was developed according to the principles I outlined in my previous entry; i.e. we spent a long time looking at examples and asking ourselves if these models actually provided us the ability to reason about and communicate the architecture of a system. We believe we have struck a reasonable balance, we are able to leverage the flexibility provided by basing this model on UML itself (so all of UML is still there to use) while specifying a subset which is useful in identifying, designing and refining a service-oriented solution. Note that we have also developed a profile, a model template, and also some examples that we are preparing to make available, also on developerWorks, in the next week so you can tell us if we have achieved our aims.
Now, my second comment. In a recent conversation with a colleague started with his asking for a reference he could cite on the OMG architecture for modeling, the M0..M3 layers of modmodeling and so on. He is also working on a model, in this case a model that represents certain managed assets for one of our runtime platforms and the model will be used to describe these assets at runtime and also in the tools his group are building. So, my question to him was why he needed the reference; well it turns out his team couldn't decide if the model they were developing was a model or meta-model or something else. Well, you know this is the kind of time-wasting discussion that we as tool vendors (and model geeks) love to engage in - but why does it matter? does it make the tool better to know this? does it help the customer if you can sit back and be satisfied that you have a valid M0 meta-model? I come back to my last entry, let's not confuse the technical nonsense we like for value for our customers... customers care about what they can do with the tool you develop, not what model or meta-model is used.
Apr 28 2005, 08:56:00 PM EDT
Permalink
|
|
The Value of Models
I was recently looking for a piece of information and was looking through Software Blueprints by David Robertson and Jaume Agusti (a good but heavy read). Interestingly I found a section on conceptual modeling that I think applies to all forms of modeling and which I would like to share here. In a section entitled "What we require of conceptual models" the authors provide a list of attributes of models, listed below. The reason I found this advise particularly timely is that we here at Rational are currently in the process of developing specific content for Service-Oriented Development of Applications within the RUP supported by specific service design models in the IBM Rational Software Modeler.
- Idealized It does not pretend to be a perfect mirror of reality.
- Germane it should represent all concepts which are stricly relevant to the problem and avoid concepts which are not.
- Precise It should be possible for the designer of a model to derive predicted consequences from it in a methodical way.
- Arguable It should be possible for those other than the designer to draw consequences from the model that the designer may not have anticipated.
- Traceable The origin of each element of the model can be justified in terms of its relationship to the problem itself or to a feature of some other model which is related to the problem.
- Communicable It should be possible, at acceptable cost, to explain the model to those in the domain to which it applies.
- Methodical Built in a stepwise manner which allows the style of construction to be inspected by other modelers.
Now, personally I have used a simple rule of thumb when looking at models and the use of models to support a given technical or business domain - does it make me go faster? (thanks to Kevin Kelly). More recently I have used an additional metric does the model of this thing tell me something about the thing that I could not tell from staring at the thing itself?. Now it would seem that these simple rules are related to the more precise list of attributes above, a list I must admit I find more useful with each read. An idealized, germane model concentrates on what is important and presents that at the right level of abstraction and detail pertinent to the user and the task at hand - it makes me go faster. Also an arguable, communicable model is one that shows me aspects of a system that I might not otherwise have been able to see. However, this leaves us with traceable and methodical, well one aspect of a lot of the models that we have described in the RUP is that they are based upon the UML and so connections and relationships between elements can easily be made to support traceability. In fact this traceability is a key aspect of both the RUP guidance on separation of models and the OMG MDA initiative. In a similar way the RUP takes an iterative approach to development that drives right down into guidance on the development of models, start by identifying the significant (relevant concepts) model elements and build out the detail in subsequent iterations providing a methodical approach.
So, going back to the opening comments, we are looking at a model for the representation of services from an architectural and design perspective (specifically as black boxes not white boxes); we idealize them by creating relationship between elements that are certainly not available in some of the standards in use today such as WSDL. We have certainly represented the concepts we believe to be germane given both the target model author as well as those to which the model will be communicated. We certainly feel that, given the examples we have modeled so far, that the model provides value to its reviewers in providing certain views that are not possible by directly reflecting the physical artifacts, and also that the model can be built iteratively. We have also connected the model with guidance in RUP such that we can describe how the model traces back to earlier models such as business process and use case models and how it can flow down into implementation models and implementation artifacts.
Incidentally one of the areas where such model representations, based upon a common underlying semantic base, have advantages over custom (dare I say domain specific) languages is that they do support the traceable attribute above. It is relatively easy to use predefined relationships in the UML (trace, refine, realize, reify, implements, use) to describe the relationship between elements in different models, across domains and across abstraction boundaries. One down-side that I would have to admit to is that precision can be a lost factor, today with the mechanisms available at our disposal in the UML to extend the language we cannot easily redefine the semantics of what is already there (and as some have pointed out, even that is not formally defined). In some cases this is a problem where the semantics of the domain being modeled are significantly different from the semantics already described in the UML. Luckily in describing a model for services and SOA the mismatch is insignificant, and when we apply the Germane factor we find that those concerns that we decide to elide are generally those with obscure or undefined semantics. In terms of custom languages then, it is often possible to define the semantics formally and/or precisely, however the tendency is to pay far too much attention to this factor than to the Idealized and Germane concerns, i.e. there is a need to reflect everything that is in the domain of concern without applying the relevance filter, and what we end up with is a model that may directly represent some artifact, but is no easier to model than it is to code and contains so much detail that we lose the ability to communicate it and argue over it.
Finally, let me be clear, this is not an argument that UML is good and DSL or custom languages are bad - I have seen good and bad UML models as well as good and bad DSLs (and that covers both textual and graphical DSLs). All I hope is that language designers and modelers take into accound these 7 principles when they start their work - and that users will always hold them to account.
Apr 05 2005, 02:02:00 PM EDT
Permalink
|
|
The Parts of an SOA Application
I am going to write a quick note here to add to some excellent comments made by Bobby Woolf in a recent posting. In his posting he correctly partitions an SOA solution into a provider part and a coordinator part, though I think what he has described is one of a number of possible patterns (for an excellent book on patterns see Bobby's book) for thinking about SOA topologies. The reason I say this is one possible pattern is that a number of customers I have talked with express a number of additional partitions; or rather they tend to break down the two that Bobby has identified into subpartitions.
For example, we can break down the provider partion into into at least two sub areas, one for business services (customer/account managemet, scheduling, HR, etc.) and a separate partition for infrastructure services (messaging, data integration, etc). In the same way we can imagine a number of sub partitions for the service coordinator area and again for example one customer separated out the process coordination area from presentation services such that the application functionality the user interacts with (in this case through a portal) interacts with a coordination partition that specifically uses a choreography engine. The purpose of this separation is to allow for the user experience to evolve independantly and according to user requirements while the process that the user is interacting with can be flexibly implemented as a coordination of both business and infrastructure services.
Again, I want to be clear that in the same way we moved from client/server (2 tiers) to 3-tier and then n-tier patterns for application development I think we have to realize that there will be n tiers in a SOA solution, categorized at a high level by Bobby's two tiers. So, before I finish I'd like to also comment on the difference between application and solution, the terms I have used here. When I think of the word application I think of a silo of code, a top-to-bottom design and implementation. When I think of solution I think of something more flexible, something that is far more business-aligned and where reuse is more prevalent. Most customers see one advantage of the move to SOA as an opportunity to build a common and enterprise-wide provider tier, i.e. all the business and infrastructure services are common across all solutions, solutions themselves are realized within the process and presentation tiers.
Mar 02 2005, 08:18:00 AM EST
Permalink
|
|
Teaching Kids to Program
For just a moment I would like to step away from the main topics of recent posts and comment on a recent posting by Don Box. I actually found Don's posting from Stefan Tilkov and I would like to add my two cents to the discussion. But, before I do, let me please make it clear that these are not comments on Don or Stefan's quest for a programming language. As father to a home schooled son I have spent some time thinking about how to bring the subject of computers and programming up and I had the desire to teach programming because, well because I enjoy it.
But, let's take a step back; why do we program? Well a program is the embodiment of the solution to a problem, and thinking back to learning programming at school it was a horrible experience because the problems were for the most part pointless. Also we have to realize that most people around us are using computers to solve problems without formal "programming", financial analysts building complex models with spreadsheets would probably be mystified if you told them they were programming. So, we have chosen to use Squeak here at home, and specifically we are using the educational packaging provided at Squeakland. Squeak is a fantastic environment for the Smalltalk programmer, but more importantly this package provides a kid-oriented package, and for $18.95 a book with progressive lesson plans for learning with Squeak. We have had great success building and racing cars, and all with drag-and-drop actions that build easy to understand scripts that our 6/7 year old son was able to extend himself. In fact, we even introduced negative numbers, degrees of a circle and more not formally in terms of mathematics but simply by watching the way the properties of his "car" changed as he moved it.
For me, this has been a fantastic tool, it is easy to use, it is very engaging and it is backed by research and practice as an educational tool. The interesting moment was, having developed a script to draw different sized polygons, to click a button and see the code behind that script, there it was, just a Smalltalk method, and you can switch back and forth. I would recommend Squeak to all of those technically minded parents looking to interest their children; it truly is a problem solving environment that you can program, or not, if you want. I also no a number of folks who have successfully introduced Squeak to their school and it has a built-in collaborative aspect to share work with other kids.
So while, I can understand the draw for those of us in computer science to look at languages that appeal to us, let's remember that kids (of all ages!) love to solve problems and Squeak is a wonderful environment to play and learn.
Feb 27 2005, 07:42:00 PM EST
Permalink
|
|
|
| S | M | T | W | T | F | S | | | | | 1 | 2 | 3 | 4 | | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 12 | 13 | 14 | 15 | 16 | 17 | 18 | | 19 | 20 | 21 | 22 | 23 | 24 | 25 | | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | | | | | Today |
|
Tooling platforms and RESTful ramblings
